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This document is a guide to the use of the OpenSSL FIPS Object Module, a software component 
intended for use with the OpenSSL cryptographic library and toolkit. It is a companion document 
to the OpenSSL FIPS 140-2 Security Policy document submitted to NIST as part of the FIPS 140-2 
validation process. It is intended as a technical reference for developers using, and system 
administrators installing, the OpenSSL FIPS software, for use in risk assessment reviews by 
security auditors, and as a summary and overview for program managers. It is intended as a guide 
for annotation and more detailed explanation of the Security Policy, and not as a replacement. In 
the event of a perceived conflict or inconsistency between this document and the Security Policy 
the latter document is authoritative as only it has been reviewed and approved by the Cryptographic 
Module Validation Program (CMVP), a joint U.S. - Canadian program for the validation of 


cryptographic products (http://csrc.nist.gov/groups/STM/cmvp/). 


Familiarity with the OpenSSL distribution and library API (Application Programming Interface) is 
assumed. This document is not a tutorial on the use of OpenSSL and it only covers issues specific 
to the FIPS 140-2 validation. For more information on the use of OpenSSL in general see the many 
other sources of information such as http://openssl.org/docs/ and Network Security with OpenSSL 
(Reference 4). 


The Security Policy document (Reference 1) is available online at the NIST Cryptographic Module 
Validation website, http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1747.pdf. 
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For more information on OpenSSL Validation Services and the OpenSSL Software Foundation see 
http://openssl.com/. For more information on the OpenSSL project see http://openssl.org/. For 
more information on NIST and the cryptographic module validation program, see 


http://esre.nist.gov/groups/STM/emvp/. 


For information and announcements regarding current and future OpenSSL related validations see 
http://openssl.org/docs/fips/fipsnotes.html. That web page also has a very quick introduction 
extracted here: 


1.1 FIPS What? Where Do I Start? 


Ok, so your company needs FIPS validated cryptography to land a big sale, and your product 
currently uses OpenSSL. You haven't worked up the motivation to wade through the entire User 
Guide and want the quick "executive summary". Here is a grossly oversimplified account: 


OpenSSL itself is not validated,and never will be. Instead a carefully defined software component 
called the OpenSSL FIPS Object Module has been created. The Module was designed for 
compatibility with the OpenSSL library so products using the OpenSSL library and API can be 
converted to use FIPS 140-2 validated cryptography with minimal effort. 


The OpenSSL FIPS Object Module validation is unique among all FIPS 140-2 validations in that 
the product is "delivered" in source code form, meaning that if you can use it exactly as is and can 
build it for your platform according to a very specific set of instructions, then you can use it as 
validated cryptography’. 


The OpenSSL library is also unique in that you can download and use it for free. 


If you require source code or build process changes for your intended application, then you cannot 
use the open source based validated module — you must obtain your own validation. This situation 
is common; see "Private Label" validation, below. 


New FIPS 140-2 validations (of any type) are slow (6-12 months is typical), expensive (US$50,000 
is typical for an uncomplicated validation), and unpredictable (completion dates are not only 
uncertain when first beginning a validation, but remain so during the process). 


Note that FIPS 140-2 validation is a complicated topic that the above summary does not adequately 
address. You have been warned! 


1.2 "Change Letter" Modifications 


If the existing validated OpenSSL FIPS Object Module is a/most what you need, but some minor 
modifications are necessary for your intended use, then it may be possible to retroactively modify 


?Either directly or via "User Affirmation" which is discussed in 85.5. 
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the original validation to include those necessary changes. The process by which this is done is 
known as the “maintenance letter” or “change letter” process. A change letter can be substantially 
faster and less expensive than obtaining a new, independent validation. 


Modifications to the FIPS module to support a new platform (operating system or compiler) are 
often compatible with the change letter process. 


1.3 The “Private Label” Validation 


OVS would prefer to work on open source based validations which benefit the OpenSSL user 
community at large. However, we understand not all work can benefit the community. We refer to 
validations based directly on the OpenSSL FIPS Object Module but not available to the community 
as “private label" validations. They are also sometimes referred to as "cookie cutter" validations. 


Many ISVs and vendors are interested in private label validations, and OVS will assist in such 
efforts with a priced engagement. An ISV or vendor usually obtains a private label validation for 
marketing or risk management purposes. For example, a company may choose to privately retain 
its validation to ensure its competitive advantage, or a company might modify the sources and 
choose to keep the changes private. 


OVS has performed numerous private validations for desktop, server, and mobile platforms with 
very competitive pricing. Often, the pricing is less than the account setup fee for closed sourced and 
locked-in solution. Trivial and uncomplicated validations can often be performed using fixed rate 
contracts to assure cost constraints. 


2. Background 


For the purposes of FIPS 140-2 validation, the OpenSSL FIPS Object Module v2.0 is defined as a 
specific discrete unit of binary object code (the “FIPS Object Module”) generated from a specific 
set and revision level of source files embedded within a source distribution. These platform 
portable source files are compiled to create the object code in an isolated and separate form. That 
object code is then used to provide a cryptographic services to external applications. The terms 
FIPS Object Module and FIPS Module elsewhere in this document refer to this OpenSSL FIPS 
Object Module object code. 


The FIPS Object Module provides an API for invocation of FIPS approved cryptographic functions 
from calling applications, and is designed for use in conjunction with standard OpenSSL 1.0.1 and 
1.0.2 distributions. These standard OpenSSL 1.0.1/1.0.2 source distributions support the original 
non-FIPS API as well as a FIPS Mode in which the FIPS approved algorithms are implemented by 
the FIPS Object Module and non-FIPS approved algorithms are disabled by default. These non- 
validated algorithms include, but are not limited to, Blowfish, CAST, IDEA, RC-family, and non- 
SHA message digest and other algorithms. 


Page 15 of 225 


User Guide - OpenSSL FIPS Object Module v2.0 


The FIPS Object Module was designed and implemented to meet FIPS 140-2, Level 1 
requirements. There are no special steps required to ensure FIPS 140-2 compliant operation of the 
FIPS Object Module, other than building, loading, and initializing the FIPS approved and HMAC- 
SHA-1 digest verified source code. This process of generating the application executable object 
from source code for all supported platforms! is documented in detail at $4 and $5. 


The FIPS Object Module provides confidentiality, integrity signing, and verification services. The 
FIPS Object Module supports the following algorithms: Triple DES, AES, CMAC, CCM, RSA (for 
digital signatures), DH, DSA/DSA2, ECDSA/ECDSA2, SHA-1, SHA-224, SHA-256, SHA-384, 
SHA-512, and HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, HMAC- 
SHA-512. The FIPS Object Module supports SP 800-90 and ANSI X9.31 compliant pseudo- 
random number generators. 


The FIPS Object Module supports the Suite B cryptographic algorithms and can be used with Suite 
B cryptography exclusively. Suite B requires 128-bit security levels and forbids use of TLS lesser 
than 1.2 (TES 1.0 and 1.1 use MDS as a PRF during key agreement). 


The FIPS Object Module v2.0 is similar in many respects to the earlier OpenSSL FIPS Object 
Module v1.2.x. The v1.2.4 was originally validated in late 2008 with validation certificate #1051; 
that original validation has been extended several times to incorporate additional platforms. 


The v1.2.x Module is only compatible with OpenSSL 0.9.8 releases, while the v2.0 Module is 
compatible with OpenSSL 1.0.1 and 1.0.2 releases. The v2.0 Module is the best choice for all new 
software and product development. 


2.1 Terminology 


2.1.1 FIPS 140-2 Specific Terminology 


During the course of multiple validations it became clear that some terminology was interpreted 
differently by OpenSSL developers, cryptographers, the CMVP and FIPS 140-2 specialists. In this 
section some of the potential confusions in terminology are discussed. 


Approved Mode 


The FIPS 140-2 Approved Mode of Operation is the operation of the FIPS Object Module when all 
requirements of the Security Policy have been met and the software has successfully performed the 
power-up and self test operation (invocation of the FIPS mode set () function call). In this 
document this Approved Mode is referred to simply as FIPS mode. 


Crypto Officer 


'By definition, for all platforms to which the validation can be extended. Per the requirements of the Security Policy, 
any change to the documented build process renders the result non-FIPS approved. 
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System administrator. The FIPS 140-2 Crypto Officer“ is the person having the responsibility and 
access privileges to install, configure, and initialize the cryptographic software. 


HMAC-SHA-] digest 


A HMAC-SHA-1 digest of a file using a specific HMAC key (the ASCII string 
“etaonrishdlcupfm’). Such digests are referred to in this document as “digests” or 
“fingerprints”. The digests are used for integrity checking to verify that the software in question 
has not been modified or corrupted from the form originally used as the basis of the FIPS 140-2 
validation. 


Note that the PGP or GPG signatures traditionally used to check the integrity of open source 
software distributions are not a component of any of the FIPS 140-2 integrity checks. 


Module 


The concept of the cryptographic module is important for FIPS 140-2, and it has subtle nuances in 
this context. Conceptually the Module is the binary object code and data in the FIPS Object Module 
for a running process. 


The “cryptographic module” is often referred to simply as “module”. That term is capitalized in 
this document as a reminder that it has a somewhat different meaning than assumed by software 
developers outside of a FIPS 140-2 context. 


Note that traditionally the executable (or shared library) file on disk corresponding to this Module 
as a running process is also considered to be a Module? by the CMVP. An integrity check of the 
entire executable file on disk prior to memory mapping is considered acceptable as long as that 
executable file does not contain any extraneous software. In this traditional case the specific 
executable file is submitted for testing and thus the precise content (as a bit string) is known in 
advance. 


In the case of the FIPS Object Module only source code is submitted for validation testing, so the 
bit string value of the binary object code in memory cannot be known in advance. A chain of 
checks beginning with the source code and extending through each step in the transformation of the 
source code into a running process was established to provide a check equivalent to that used by 
more traditional object based validations. 


“The term “Officer” does not imply a requirement for a military or government official, although some military or 
government organizations may choose to restrict the performance of this system administration role to certain official 
capacities. 

`Presumably because the transformations of the disk resident file contents performed by the runtime loader are 
considered to be well understood and sufficiently minimal. 

“The definition of what constitutes “extraneous” is not formally specified and subject to interpretation. 
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The chain of checks works backwards from the software as resident in memory for a process to the 
executable program file from which the process was created (the existing precedent), then to the 
FIPS Object Module used to link the program file, and finally to the original source files used to 
create the FIPS Object Module. Each of those stages can be thought of as antecedents of the 
Module, and the integrity of each needs to be verified to assure the integrity of the Module. 


2.1.2 General Glossary 


ABI 
AES 
AES-NI 
ARM 


API 
Blowfish 
CAST 
CC 
CCM 


Application Binary Interface 

Advanced Encryption Standard 

AES New Instructions 

a processor instruction set architecture developed by 
ARM Holdings 

Application Programming Interface 

A cryptographic algorithm not allowed in FIPS mode 
A cryptographic algorithm not allowed in FIPS mode 
Common Criteria 

Counter with Cipher Block Chaining-Message 
Authentication Code, a mode of operation for 
cryptographic block ciphers 

Cofactor Diffie-Hellman, a Discrete Logarithm 
Cryptography (DLC) primitive, see SP 800-56A 
Cryptographic Algorithm Validation Program, see 
http://csrc.nist.gov/groups/STM/cavp/ 

Cipher-based MAC, a block cipher-based message 
authentication code algorithm 

Cryptographic Module Validation Program, see 
http://csrc.nist.gov/groups/STM/cmvp/ 

DRBG flavor 

Diffie-Hellman, a FIPS approved cryptographic 
algorithm 

Dynamic Link Library, a shared library for the 
Microsoft Windows OS 

Deterministic Random Bit Generator, see SP 800-90 
Digital Signature Algorithm, a FIPS approved 
cryptographic hash function 

DSA as defined in FIPS 186-3 

Elliptic Curve 

Elliptic Curve Cryptography (see EC) 

Elliptic Curve Diffie-Hellman, a variant of Diffie— 
Hellman used as an anonymous key agreement 
protocol 
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ECDSA Elliptic Curve Digital Signature Algorithm, a variant 
of DSA which uses ECC 

ECDSA2 ECDSA as defined in FIPS 186-3 

ELF Executable and Linkable Format, the standard binary 
file format for Unix-like systems on x86. 

ENGINE An OpenSSL mechanism for interfacing with external 
cryptographic implementations 

EVP ENVelope encryption, an OpenSSL API that provides 
a high-level interface to cryptographic functions 

FIPS Federal Information Processing Standards, see 
http://www.itl.nist.gov/fipspubs/ 

FIPS 140-2 See http://csrc.nist.gov/publications/fips/fips140- 
2/fips1402.pdf 


FIPS Object Module the special monolithic object module built from the 
special source distribution! identified in the Security 


Policy 

GCM Galois/Counter Mode, a mode of operation for 
symmetric key cryptographic block ciphers 

GPG See PGP 

GUI Graphical User Interface 

HMAC Hash Message Authentication Code, a mechanism for 
message authentication using cryptographic hash 
functions 

TA Information Assurance 

IDEA A cryptographic algorithm not allowed in FIPS mode 

IKE Internet Key Exchange, a protocol for exchanging 
information required for secure communication. 

IP Internet Protocol, a network communications protocol 

IPsec Internet Protocol Security, a protocol suite for 


securing IP communications by authenticating and 
encrypting each IP packet 


IT Information Technology 

IUT Implementation Under Test 

KAT Known Answer Test 

MASM The Microsoft assembler, no longer supported by 
OpenSSL 

MD2 A cryptographic algorithm not allowed in FIPS mode 

NEON an architecture extension for ARM Cortex™-A series 
processors, 


Roughly speaking, this special source distribution was created from the OpenSSL-fips-2_0-stable branch in 
the CVS source code repository with the command make VERSION=fips-2.0 TARFILE=openssl-fips- 
2.0.tar -f Makefile.fips dist. 
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the open source Netwide ASseMbler, see 

http: //www.nasm.us/ 

Name IDentifier for extracting information from a 
certificate Distinguished Name. 

National Institute of Science and Technology, see 
http://www.nist.gov/ 

See Operational Environment 


Operational Environment The FIPS 140-2 term for "platform", though 


with a somewhat different meaning than in the 
software engineering world 

Operating System 

The OpenSSL Software Foundation 

OpenSSL Validation Services, Inc. 

an instruction for x86 processors which performs 
carry-less multiplication of two 64-bit operands 
Pretty Good Privacy, an encrypted E-mail program 
Public-Key Cryptography Standard #1 

Public-Key Cryptography Standard #3 

Power Up Self Test, an initialization process required 
by FIPS 140-2 

Pseudo-Random Number Generator 

Random Number Generator 

Probabilistic Signature Scheme, a provably secure 
way of creating signatures with RSA 
Rivest-Shamir-Adleman, a public key cryptographic 
algorithm 

Secure Hash Algorithm, a cryptographic hash function 
Streaming SIMD Extension 2, an extension of the x86 
instruction set 

Secure SHell, a network protocol for secure data 
communication 

Secure Socket Layer, a predecessor to the TLS 
protocol 

Supplemental Streaming SIMD Extensions 3, an 
extension of the x86 instruction set 

a set of cryptographic algorithms created by the 
National Security Agency 

Transport Layer Security, a cryptographic protocol 
providing communication security over IP connections 
Virtual Memory System, an operating system that runs 
on VAX, Alpha and Itanium-based families of 
computers (now obsolete) 
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x86 a family of instruction set architectures originally 
defined by Intel 

XIS XEX Tweakable Block Cipher with Ciphertext 
Stealing 

XTS-AES a cryptographic algorithm specified in SP 800-38E 


2.2 The FIPS Module and Integrity Test 


The FIPS Object Module is generated in binary file format, with an embedded pre-calculated 
HMAC-SHA-1 digest covering the module? as it is loaded into application address space. The 
Module integrity check consists of recalculating that digest from the memory areas and comparing 
it to the embedded value which resides in an area not included in the calculated digest’. This “in- 
core hashing” integrity test is designed to be both executable format independent and fail-safe. 


For this scenario the Module is the text and data segments as mapped into memory for the running 
application. 


The term Module is also used, less accurately, to designate the antecedent of that memory mapped 
code and data, the FIPS Object Module file residing on disk. 


The FIPS Object Module is generated from source code, so the integrity of that source must also be 
verified. The single runtime digest check typical of pre-built binary files is replaced by a chain of 
digest checks in order to validate that the running code was in fact generated from the original 
source code. As before the term Module properly designates the text and data segments mapped 
into memory, but is also more loosely used to reference several levels of antecedents. These levels 
are discussed below. 


2.3 The FIPS Integrity Test 


The FIPS 140-2 standard requires an integrity test of the Module to verify its integrity at 
initialization. In addition to the requirement that the integrity test validate that the FIPS Object 
Module code and data have not changed, two additional implicit requirements for the integrity test 
were identified during the validation process. 


2.3.1 Requirement for Exclusive Integrity Test 


An integrity test that is merely guaranteed to fail if any of the cryptographic module software 
changes is not sufficient. It is also necessary that the integrity test not fail if the cryptographic 
module software is not directly corrupted, even though the application referencing the 
cryptographic module may be damaged with unpredictable consequences for the correct 


*Specifically, the text and read-only data segments which constitute the initialized components of the module. 


?If the digest value resided in the data area included in the calculation of that digest, the calculated value of the digest 
would itself be an input into that calculation. 
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functioning of that application. Another way of looking at this is that as application failures are out 
of scope of the integrity test there needs to be some level of assurance that changes to application 
software do not affect the cryptographic module integrity test”. 


This requirement is met with an in-core integrity test that carefully excludes any extraneous'' object 
code from the digest calculation and verification. 


2.3.2 Requirement for Fixed Object Code Order 


The relative order of all object code components within the module must be fixed and invariant. 
The usual linking process does not care about the relative order of individual object modules, e.g. 
both 


gcc -o runfile alpha.o beta.o gamma.o 
and 
gcc -o runfile beta.o alpha.o gamma.o 


produce functionally identical executable files. Likewise, the order of object modules in a static 
link library is irrelevant: 


ar r libxxx.a alpha.o beta.o gamma.o 
and 
ar r libxxx.a beta.o alpha.o gamma.o 


produce interchangeable link libraries, and a given application may not incorporate all of the object 
modules contained with the link library when resolving references. For the FIPS Object Module it 
was required that any such omission or rearrangement of the Module object modules during the 
application creation process not occur. This requirement is satisfied by simply compiling all the 
source code into a single monolithic object module: 


ld -r -o fipscanister.o fips start.o ... fips end.o 


with all the object modules between the £ips start.o and fips end.o modules that define the 
low and high boundaries of a monolithic object module. All subsequent reference to this 
monolithic object module will preserve the relative order, and presence, of the original object code 
components. 


2.4 The File Integrity Chain 


This assurance was given by showing during testing that corruption of code or data outside of the memory area 
containing the FIPS Object Module did not result in an integrity test failure. 
"The definition of what constitutes "extraneous" is not formally specified and thus subject to interpretation. 
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Most validated products consisting of a pre-built binary executable implement the module integrity 
check as a digest check over portions of that executable file or the corresponding memory mapped 
image. For the FIPS Object Module the module integrity check instead takes the form of a chain of 
digest checks beginning with the source files used for the CMVP validation testing. Note that 
while this chain of checks is more complex, 1t provides much more visibility for independent 
verification compared to the case of validated pre-built binary executables. With the FIPS Object 
Module the prospective user can independently verify that the runtime executable does indeed 
directly derive from the same source that was the basis of the validation. 


2.4.1 Source File (Build Time) Integrity 


“Build time” is when the FIPS Object Module is created from the OpenSSL FIPS source 
distribution, in accordance with the Security Policy. 


The first file integrity check occurs at build time when the HMAC-SHA-1 digest of the distribution 
file is calculated and compared to the stored value published in the Security Policy (Appendix B). 


Because the source files reside in this specific distribution and cannot be modified these source 
files are referred to as sequestered files. 


Note that a means to calculate the HMAC-SHA-1 digest is required in order to perform this 
integrity check. A “bootstrap” standalone HMAC-SHA-1 utility, fips standalone shal,is 
included in the distribution. This utility is generated first before the sequestered files are compiled 
in order to perform the integrity check. Appendix C gives an example of an equivalent utility. 


2.4.2 Object Module (Link Time) Integrity 


“Link time” is when the application is linked with the previously built and installed FIPS Object 
Module to generate an executable program. 


The build process described in the Security Policy results in the creation of an object module, 
fipscanister.o, and a matching digest file, fipscanister.o.shal. This FIPS Object 
Module contains the object code corresponding to the sequestered source files (object code for 
FIPS specific functions such as FIPS_mode_set () and for the algorithm implementations). 


The link time integrity check occurs when the FIPS Object Module is used to create an application 
executable object (binary executable or shared library). The digest stored in the installed file 
fipscanister.o.shal must match the digest calculated for the fipscanister.o file. 


Note that except in the most unusual circumstances the FIPS Object Module itself 


(fipscanister .o) is not linked directly with application code. Instead the FIPS Object Module 
is embedded in the OpenSSL libcrypto library (libcrypto.a/libcrypto.so) which is then referenced in 
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the usual way by the application code. That combination is known as a "FIPS capable" OpenSSL 
library and is discussed in more detail in section 2.5. 


2.4.3 Application Executable Object (Run Time) Integrity 


Application “run time” occurs when the previously built and installed application program is 
invoked. Unlike the previous step this invocation is usually performed repeatedly. 


The runtime integrity check occurs when the application attempts to enable FIPS mode via the 
FIPS_mode set () function call. The digest embedded within the object code from 
fipscanister.o must match the digest calculated for the memory mapped text and data areas. 


2.5 Relationship to the OpenSSL API 


The FIPS Object Module is designed for indirect use via the OpenSSL API. Applications linked 
with the "FIPS capable" OpenSSL libraries can use both the FIPS validated cryptographic functions 
of the FIPS Object Module and the high level functions of OpenSSL. The FIPS Object Module 
should not be confused with OpenSSL library and toolkit or any specific official OpenSSL 
distribution release. 


A version of the OpenSSL product that is suitable for use with the FIPS Object Module is a FIPS 
Compatible OpenSSL. 


When the FIPS Object Module and a FIPS compatible OpenSSL are separately built and installed 
on a system, with the FIPS Object Module embedded within the OpenSSL library as part of the 
OpenSSL build process, the combination is referred to as a FIPS capable OpenSSL. 


Summary of definitions 
The FIPS Object Module is the FIPS 140-2 validated module described in the Security Policy 


A FIPS compatible OpenSSL is a version of the OpenSSL product that is designed for compatibility with 
the FIPS Object Module API 


AFIPS capable OpenSSL is the combination of the separately installed FIPS Object Module along with a 
FIPS compatible OpenSSL. 


Table 2.5 


The OpenSSL libraries, when built from a standard OpenSSL distribution with the “fips” 
configuration option for use with the FIPS Object Module, will contain the usual non-FIPS 
algorithms and non-cryptographic supporting functions, and the non-FIPS algorithm disabling 
restrictions. 
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Note that use of individual object modules comprising the monolithic FIPS Object Module is 
specifically forbidden by FIPS 140-2 and the CMVP”. In the absence of that restriction the 
individual object modules would just be incorporated directly in the OpenSSL liberypto.a 
library. The monolithic FIPS Object Module must be used in its entirely and cannot be edited to 
accommodate size constraints. 


Various non-FIPS algorithms such as Blowfish, IDEA, CAST, MD2, etc. are included in the 
OpenSSL libraries (depending on the . /config options specified in addition to fips). For 
applications that do not utilize FIPS 140-2 cryptography, the resulting libraries are drop-in 
compatible with the libraries generated without the £ips option (a deliberate design decision to 
encourage wider availability and use of FIPS 140-2 validated algorithms). The converse is not true: 
a non-FIPS OpenSSL library cannot be substituted for the FIPS Compatible library because the 
FIPS specific function calls will not be present (such as FIPS mode set () ). 


2.6 FIPS Mode of Operation 


Applications that utilize FIPS mode must call the FIPS mode set () function. After successful 
FIPS mode initialization, the non-FIPS algorithms will be disabled by default. 

The FIPS Object Module together with a compatible version of the OpenSSL product can be used 

in the generation of both FIPS mode and conventional applications. In this sense, the combination 

of the FIPS Object Module and the usual OpenSSL libraries constitutes a “FIPS capable API”, and 
provide both FIP approved algorithms and non-FIPS algorithms. 


2.6.1 FIPS Mode Initialization 


Only one initialization call, FIPS mode set (), is required to operate the FIPS Object Module 
in a FIPS 140-2 Approved mode, referred to herein as "FIPS mode". When the FIPS Object 
Module is in FIPS mode all security functions and cryptographic algorithms are performed in 
Approved mode. Use ofthe FIPS mode set () function call is described in $5. 


A power-up self-test is performed automatically by the FIPS mode set () call, or optionally at 
any time by the FIPS selftest () call (see Appendix D). If any power-up self-test fails the 


P? Actually, to encourage use of fipscanister.o even in non-FIPS mode applications, a copy is incorporated into 
liberypto.a, but special care is taken to preclude its usage in FIPS enabled applications. The fipsld utility 
provided in the FIPS compatible OpenSSL distributions prevents that usage as follows. In static link context that is 
achieved by referencing the official fipscanister.o first on the command line., and in dynamic link context by 
temporarily removing it from libcrypto.a. This removal is necessary because dynamic linking is commonly 
accompanied by -whole-archive, which would force both copies of fipscanister.o into the shared library. 
Note the integrity check is designed as a failsafe precaution in the event of link errors -- even if two copies are 
included into the application in error, the integrity check will prevent the use of one copy for the integrity test and the 
other for the actual implementation of cryptography. In other words, if both the official £àpscanister.o and the 
unvalidated version that is embedded in liberypto.a both end up in an executable binary, and if 

FIPS mode set () returns success, the unvalidated copy will not be used for cryptography. 
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internal global error flag FIPS_selftest_fail is set and subsequently tested to prevent 
invocation of any cryptographic function calls. 


The internal global flag FIPS mode is set to FALSE indicating non-FIPS mode by default. The 
FIPS_mode set () function verifies the integrity of the runtime executable using a HMAC- 
SHA-1 digest computed at build time. Ifthe digests match, the power-up self-test is then 
performed. If the power-up self-test is successful FIPS mode set () sets the FIPS_mode flag 
to TRUE and the FIPS Object Module is in FIPS mode. 


2.6.2 Algorithms Available in FIPS Mode 


Only the algorithms listed in tables 4a and 4b of the Security Policy are allowed in FIPS mode. 
Note that Diffie-Hellman and RSA are allowed in FIPS mode for key agreement and key 
establishment even though they are “Non-Approved” for that purpose. RSA for sign and verify is 
“Approved” and hence also allowed, along with all the other Approved algorithms listed in that 
table. 


The OpenSSL library attempts to disable non-FIPS algorithms. when in FIPS mode. The disabling 
occurs on the EVP_* APIs and most low level function calls. Failure to check the return code 
from low level functions could result in unexpected behavior. Note also that sufficiently creative or 
unusual use of the API may still allow the use of non-FIPS algorithms. The non-FIPS algorithm 
disabling is intended as an aid to the developer in preventing the accidental use of non-FIPS 
algorithms in FIPS mode, and not as an absolute guarantee. It is the responsibility of the application 
developer to ensure that only FIPS algorithms are used when in FIPS mode. 


OpenSSL provides mechanisms for interfacing with external cryptographic devices, such as 
accelerator cards, via “ENGINES.” This mechanism is not disabled in FIPS mode. In general, if a 
FIPS validated cryptographic device is used with OpenSSL in FIPS mode so that all cryptographic 
operations are performed either by the device or the FIPS Object Module, then the result is still 
FIPS validated cryptography. 


However, if any cryptographic operations are performed by a non-FIPS validated device, the result 
is use of non-validated cryptography. It is the responsibility of the application developer to ensure 
that ENGINES used during FIPS mode of operation are also FIPS validated. 


2.7 Revisions of the 2.0 Module 


Existing FIPS 140-2 validations can be retroactively modified, within defined limits, via the 
"maintenance letter" or "change letter" process. Change letter modifications are typically done to 
correct minor "non-cryptographically significant" bugs or, most commonly, to add support for new 
platforms. Change letter actions are usually less expensive and faster than a full validation; and are 
an attractive option to the software vendor desiring to use the FIPS module for a platform not 
currently covered by the validation. 


Page 26 of 225 


User Guide - OpenSSL FIPS Object Module v2.0 


Several change letter modifications were in process prior to the formal award of the initial 
OpenSSL FIPS Object Module v2.0 validation. More change letters are anticipated over the 
lifetime of the validation. For all past validations we have always been careful to introduce any 
changes in a way that will not impact any previously tested platforms, so that the most recent 
revision of the module can be used for new deployments on any platform. 


The history of new revisions include: 


2.0.1 
2.0.1 
2.0.1 
2.0.1 
2.0.1 
2.0.1 
2.0.2 
2.0.2 
2.0.3 
2.0.3 
2.0.3 
2.0.3 
2.0.3 
2.0.3 
2.0.3 
2.0.3 
2.0.3 
2.0.4 
2.0.5 
2.0.5 
2.0.5 
2.0.5 


2.0.5 
2.0.5 
2.0.5 
2.0.5 
2.0.5 
2.0.5 


2.0.6 
2.0.7 


Addition of Apple iOS 5.1 on ARMv7 

Addition of WinCE 5.0 on ARMv7 

Addition of Linux 2.6 on PowerPC32-e500 (PPC) 

Addition of DSP Media Framework 1.4 on TI C64x+ 

Addition of WinCE 6.0 on ARMv7 

Addition of Android 4.0 on OMAP 3 (ARMv7) 

Addition of NetBSD 5.1 on PowerPC32-e500 (PPC) 

Addition of NetBSD 5.1 on Intel Xeon 5500 (x86) 

Addition of Win2008 on Xeon E3-1220v2 (x86) 

Addition of RHEL 32/64 bit on Xeon E3-1220v2 (x86) under vSphere 
Addition of Win7 on Intel Core 15-2430M (x86) with AES-NI 

Addition of Android 4.1/4.2 on Nvidia Tegra 3 (ARMv7) with/without NEON 
Addition of WinEC7 on Freescale 1.MX53xD (ARMv7) with/without NEON 
Addition of Android 4.0 on Qualcomm Snapdragon APQ8060 (ARMv7) 
Addition of VMware Horizon Module on Qualcomm MSM8X60 (ARMv7) 
Addition of Apple OS X 10.7 on Intel Core 17-3615QM (x86) 

Addition of Apple iOS 5.0 on ARM Cortex A8 (ARMv7) 

Addition of OpenWRT 2.6 on MIPS 24Kc 

Addition of QNX 6.4 on Freescale 1.MX25 (ARMv4) 

Addition of Apple iOS 6.1 on Apple A6X SoC (ARMv7s) 

Addition of eCos 3 on Freescale 1.MX27 926ejs (ARMvSTEJ) 

Addition of VMware Horizon Workspace 1.5 under vSphere on Intel Xeon E3-1220 
(x86) with/without AES-NI 

Addition of Ubuntu 13.04 on AM335x Cortex-A8 (ARMv7) with/without NEON 
Addition of Linux 3.8 on ARM926 (ARMvSTEJ) 

Addition of Linux 3.4 under Citrix XenServer on Intel Xeon E5-2430L (x86) 
with/without AES-NI 

Addition of Linux 3.4 under VMware ESX on Intel Xeon E5-2430L (x86) 
with/without AES-NI 

Addition of Linux 3.4 under Microsoft Hyper-V on Intel Xeon E5-2430L (x86) 
with/without AES-NI 

Addition of Apple iOS 6.0 on Apple A5 / ARM Cortex-A9 with/without NEON 
Removal of Dual EC DRBG (no platforms) 

Addition of Linux 2.6 on Freescale e500v2 (PPC) 
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2.0.7 
2.0.7 
2.0.7 
2.0.7 
2.0.7 
2.0.7 
2.0.7 
2.0.7 
2.0.8 
2.0.8 
2.0.8 
2.0.8 
2.0.8 
2.0.9 


2.0.9 
2.0.9 


2.0.9 
2.0.10 


2.0.10 
2.0.10 
2.0.10 


2.0.10 


2.0.11 
2.0.11 
2.0.11 
2.0.11 
2.0.11 
2.0.11 


2.0.11 
2.0.11 
2.0.12 
2.0.13 
2.0.13 
2.0.13 
2.0.13 
2.0.13 
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Addition of AcanOS 1.0 on Intel Core 17-3612QE (x86) 

Addition of AcanOS 1.0 on Intel Core 17-3612QE (x86) with AES-NI 
Addition of AcanOS 1.0 on Feroceon 88FR131 (ARMv5) 

Addition of FreeBSD 8.4 on Intel Xeon E5440 (x86) 

Addition of FreeBSD 9.1 on Xeon E5-2430L (x86) 

Addition of FreeBSD 9.1 on Xeon E5-2430L (x86) with AES-NI 

Addition of ArbOS 5.3 on Xeon E5645 (x86) 

Addition of Linux ORACLESP 2.6 on ASPEED AST2100 (ARMv5) 

Addition of Linux ORACLESP 2.6 on ServerEngines PILOT3 (ARMv5) 
Addition of Linux ORACLESP 2.6 on ASPEED AST-Series (ARMv5) 
Addition of Linux ORACLESP 2.6 on Emulex PILOT 3 (ARMv5) 

Addition of FreeBSD 9.2 on Xeon E5-2430L (x86) with-without AES-NI 
Addition of FreeBSD 10.0 on Xeon E5-2430L (x86) with/without AES-NI 
Addition of FreeBSD 8.4 32-bit on Xeon E5440 (x86) 

Addition of VMware Horizon Workspace 2.1 x86 under vSphere ESXi 5.5 on Intel 
Xeon E3-1220 (x86) with/without AES-NI 

Addition of QNX 6.5 on ARMV4 Freescale i.MX25 (ARMv4) 

Addition of Apple iOS 7.1 64-bit on ARMv8 Apple A7 (ARMv8) with/without 
NEON 

Addition of TS-Linux 2.4 on ARMv4 

Addition of iOS 8.1 64-bit on Apple A7 (ARMv8) with/without NEON and Crypto 
Extensions 

Addition of VxWorks 6.9 on Freescale P2020 (PPC) 

Addition of iOS 8.1 32-bit on Apple A7 (ARMv8) with/without NEON 
Addition of Android 5.0 32-bit on Qualcomm APQ8084 (ARMv7) with/without 
NEON 

Addition of Android 5.0 64-bit on SAMSUNG Exynos7420 (ARMv8) with/without 
NEON and Crypto Extensions 

Addition of VxWorks 6.7 on Intel Core 2 Duo (x86) 

Addition of AIX 6.1 32bit Power 7 (PPC) 

Addition of AIX 6.1 64bit Power 7 (PPC) 

Addition of AIX 7.1 32bit Power 7 (PPC) 

Addition of AIX 7.1 64bit Power 7 (PPC) 

Addition of DataGravity Discovery Series OS V2.0 Intel Xeon E52420 (x86) 
with/without AES NI 

Addition of AIX 6.1 32bit Power 7 (PPC) with/without optimizations 
Addition of Ubuntu 12.04 Intel Xeon E52430L (x86) with/without AES-NI 
Addition of Linux 3.10 Intel Atom E3845 (x86) with/without AES-NI 
Addition of AIX 7.1 32bit on PPC 

Addition of AIX 7.1 64bit on PPC with optimizations 

Addition of AIX 7.1 32bit on PPC with optimizations 

Addition of AIX 7.1 64bit on PPC 

Addition of AIX 7.2 32bit on PPC 
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2.0.13 Addition of AIX 7.2 32bit on PPC with optimizations 
2.0.13 Addition of AIX 7.2 64bit on PPC 

2.0.13 Addition of AIX 7.2 64bit on PPC with optimizations 
2.0.13 Addition of AIX 7.2 32bit on PPC 

2.0.13 Addition of AIX 7.2 64bit on PPC 

2.0.14 Addition of ExtremeXOSLinux 3.1 on MIPS 

2.0.15 SurfWare 7.2 on TI c64 DSP 


Revisions 2.0.6 and 2.0.7 constitute an unfortunate perversity. The 2.0.6 revision removed the Dual 
EC DRBG implementation which at the time of submission of the official paperwork (Maintenance 
Letter) on January 20, 2014 had already been officially repudiated by NIST. However, approval of 
the 2.0.6 revision languished for more than six months. In the meantime eleven" new platforms 
were tested using the most recent officially approved revision, 2.0.5, plus platform specific 
modifications, resulting in revision 2.0.7 which still included the Dual EC DRBG 
implementation'*. The official paperwork for the 2.0.7 revision was submitted months after 2.0.6 
but both revisions were approved with the span of a single week, with the preverse result that the 
2.0.7 revision of the OpenSSL FIPS Object Module still contained the deprecated and disgraced 
Dual EC DRBG. It was again (and permanently) removed with revision 2.0.8. 


Note that 2.0.10 will be the last revision for the #1747 validation, due to the risk of a new "hostage" 
situation (see http://openssl.com/fips/aftermath.html). 


2.8 Prior FIPS Object Modules 


The 2.0 version of the FIPS Object Module is the latest in a series of open source based validated 
modules derived from the OpenSSL product. As with those prior modules this version is delivered 
in source code form and results in a statically linked object module. 


There are some differences with respect to the previous version 1.2.x series of modules which have 
been widely used, both directly as validated for certificate #1051, and indirectly as models for 
separate "private label" validation. Some of the key differences are: 


1. The source code distribution for the 1.2.x FIPS modules was a modified OpenSSL 
distribution that contained a considerable amount of code superfluous to the generation of 
the FIPS module. The 2.0 FIPS module is provided in a separate dedicated source 
distribution containing far less extraneous code. 


POnly ten new platforms acually appeared with the 2.0.7 revision due to an unexplained "paperwork error" at the 
CAVP which required repeating some of the algorithm tests for the eleventh platform which was thus omitted from the 
2.0.7 revision. The eleventh platform will be included in a future revision. 

“Approval of the removal of Dual EC DRBG implementation was far from certain; several interested parties including 
one accredited test lab were absolutely certain it would not be permitted. While that issue was pending we did not want 
to put the eleven new platforms at risk by testing on a revision that omitted Dual EC DRBG. As it was the unfortunate 
sponsors of those new platforms had to wait up to six months for final official approval. 
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The 1.2.x FIPS modules were compatible only with the "FIPS capable" 0.9.8 baseline. The 
2.0 FIPS module is compatible with the "FIPS capable" 1.0.1/1.0.2 baseline, but will not 
remain usable with future OpenSSL versions (1.1.0 and later). 


The 2.0 FIPS module has a significantly faster POST performance. The slow POST for the 
1.2.x modules was a significant impediment to use on some low-powered processors. 


The 2.0 FIPS module contains several additional cryptographic algorithms, including all of 
Suite B. 


The 2.0 FIPS module more directly accommodates cross-compilation, as both native and 
cross-compilation now use the same technique for determining the module integrity digest 
at build time. 


Future FIPS Object Modules 


The open source based OpenSSL FIPS Object Module validations are difficult and expensive, and 
as a result have been done infrequently. The long intervals between validations compound the 
difficulty of obtaining each new validation: 


l. 


2. 


3. 


The companion OpenSSL product changes significantly, requiring significant rework to 
both that product and the new FIPS module for the "FIPS capable" functionality; 


A number of new and relatively untried algorithm tests are introduced by the CAVP; 


New validation requirements are introduced by the CMVP. 


The result is a vicious cycle: the new validation takes much more effort and time, during which 
these factors continue to mount (the CMVP can and does introduce new requirements in the course 
of an ongoing validation). That cost and difficulty becomes an intimidating factor for planning, and 
soliciting funding and/or collaboration for, the next validation. 


In order to try and bypass this cycle OVS would like to perform open source based validations 
more frequently, ideally as often as the interval required to obtain a validation which is about a 
year. That would mean that at any point in time there will be a relatively current completed 
validation and a new validation in process. New features or modifications that would adversely 
impact the ongoing validation can then be deferred to the next upcoming one. New requirements 
and algorithm tests can be addressed a few at a time instead of all at once in a huge onslaught. 


Potential sponsors of such an effort are welcome, and are invited to contact OVS to express their 
interest. 


Page 30 of 225 


User Guide - OpenSSL FIPS Object Module v2.0 


2.10 Clone Validations 


Section G.8 of the Implementation Guidance document (reference 3) defines an odd type of clone 
or copycat validation, the "Alternative Scenario 1A" or "Alternative Scenario 1B" validation. 
Basically these clone validations allow a vendor to copy an existing validation with minimal 
cosmetic changes. Since most validated cryptographic modules are based on proprietary software, 
such clone validations are most feasible for copying the validations based on open source licensed 
modules, which is to say the OpenSSL FIPS Object Module validations. 


And indeed a number of vendors have taken advantage ofthe Alternative Scenario 1A/1B 
provision to create clone validations. These validations are often referred to as "re-brands" by the 
test labs, as they basically consist of changing the title page of the Security Policy document and 
supplying a proprietary brand name for what is still the OpenSSL FIPS Object Module software. 


The known clone validations” are: 


Validation Rebranded Module Name Module Notes 
$ Revision(s) 
2631 Intel OpenSSL FIPS Object Module 2.0.5, 2.0.8 1 
2575 Cellerypt Secure Core 3 FIPS 140-2 Module 2.0.10 
2473 OpenSSL FIPS Object Module 2.0.9 - 2.0.10 2 
2454 LogRhythm FIPS Object Module Version 6.3.4 2.0.9 and prior 
2422 Nimble Storage OpenSSL FIPS Object Module 2.0.9 and prior 1 
2412 CellTrust Cryptographic Module (CTCM) 2.0.5 
2398 OpenSSL FIPS Object Module 2.0.9 - 2.0.12 2 
2391 HP TippingPoint Crypto Core OpenSSL 2.0.8 
2096 WatchDox® CryptoModule unknown 3 
1747 OpenSSL FIPS Object Module 2.0.10 and prior 

Table 2.10a 


Note 1: the use of the OpenSSL name conflicts with the OpenSSL license and trademark. OpenSSL currently 
lacks the financial and legal resources to pursue such violations, which are regretably common. The preferred 
term for a third party product based on OpenSSL is "...for OpenSSL", as in "AcmeCo FIPS Object Module for 
OpenSSL". 


Known and currently valid; a number of clone validation were delisted by the RNG transition of January 2016. 
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Note 2: these two clone validations were done by OpenSSL, for reasons too tediously and perversely dreary to 
permit succinct explanation here. For background see the "hostage" situation trilogy concluding with the 
dicsussion at http: //openssl.com/fips/aftermath.html. 


Note 3: this validation is clearly based on the OpenSSL FIPS Object Module, but the reference revision is 
unknown and the Security Policy omits any mention of OpenSSL, the module tarball, or the secure 
distribution requirement imposed on other OpenSSL related validations. 


Since these clone validations are based on the same OpenSSL Object Module software, which is 
available under a no-cost open source license, the formally tested platforms ("Operational 
Environments") for these clone validations are available for use by anyone. Some of the clone 
validations merely copy platforms from the original OpenSSL FIPS Object Module validations, but 
some add new platforms. 


Thus, the list of formally tested platforms for the prospective user ofthe OpenSSL FIPS Object 
Module is the union of all platforms for the original #1747 validation plus all clone validations. 
This union is shown in the following table (current as of May 10, 2016 and subject to change). 
Note this table was constructed from the platform descriptions as shown on the NIST CMVP web 


site (http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all. htm), and those 
descriptions have been known to contain errors. 


This table has 346 entries, of which only 178 are unique due to duplication among multiple 
validations. 


IMPORTANT NOTE: the latest revision of the OpenSSL FIPS Object Module, for any validation, 
will build and execute correctly for any platform in this table (e.g. revision 2.0.13 form openssl- 
fips-2.0.12.tar.gz). This is because each successive revision is carefully designed to retain full 
support for all previously formally tested platforms. However, any given platform in this table may 
not be righteous with respect to FIPS 140-2, as it may only be listed in a validation than names 
module revision(s) earlier than the most current revision. So, be sure to check each of the 
validation(s) listed for the platform of interest to be sure the module revision you are using is listed 
by at least one of those validations. If not you will need to regress to an earlier revision even though 
the module build from the later revision is fully functionally equivalent. 


Platform Validation 
AcanOS 1.0 running on Feroceon 88FR131 (ARMv5) (gcc Compiler Version 4.5.3) 1747 
AcanOS 1.0 running on Feroceon 88FR131 (ARMv5) (gcc Compiler Version 4.5.3) 2391 
AcanOS 1.0 running on Feroceon 88FR131 (ARMv5) (gcc Compiler Version 4.5.3) 2454 
AcanOS 1.0 running on Intel Core 17-3612QE (x86) with AES-NI (gcc Compiler Version 4.6.2) 1747 
AcanOS 1.0 running on Intel Core 17-3612QE (x86) with AES-NI (gcc Compiler Version 4.6.2) 2391 
AcanOS 1.0 running on Intel Core 17-3612QE (x86) with AES-NI (gcc Compiler Version 4.6.2) 2454 
AcanOS 1.0 running on Intel Core 17-3612QE (x86) without AES-NI (gcc Compiler Version 4.6.2) 1747 
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Platform Validation 

AcanOS 1.0 running on Intel Core 17-3612QE (x86) without AES-NI (gcc Compiler Version 4.6.2) 2391 
AcanOS 1.0 running on Intel Core 17-3612QE (x86) without AES-NI (gcc Compiler Version 4.6.2) 2454 
AIX 6.1 32-bit running on IBM POWER 7 (PPC) (IBM XL C/C++ for AIX Compiler Version V13.1) |2398 
AIX 6.1 32-bit running on IBM POWER 7 (PPC) with optimizations (IBM XL C/C++ for AIX 2398 
Compiler Version V10.1) 

AIX 6.1 64-bit running on IBM POWER 7 (PPC) (IBM XL C/C++ for AIX Compiler Version V13.1) |2398 
AIX 6.1 64-bit running on IBM POWER 7 (PPC) with optimizations (IBM XL C/C++ for AIX 2398 
Compiler Version V10.1) 

AIX 7.1 32-bit running on IBM POWER 7 (PPC) (IBM XL C/C++ for AIX Compiler Version V13.1) | 2398 
AIX 7.1 64-bit running on IBM POWER 7 (PPC) (IBM XL C/C++ for AIX Compiler Version V13.1) |2398 
Android 2.2 (gee Compiler Version 4.4.0) 2391 
Android 2.2 running on OMAP 3530 (ARMv7) with NEON (gcc Compiler Version 4.1.0) 1747 
Android 2.2 running on OMAP 3530 (ARMv7) with NEON (gcc Compiler Version 4.1.0) 2391 
Android 2.2 running on OMAP 3530 (ARMv7) with NEON (gcc Compiler Version 4.1.0) 2454 
Android 2.2 running on Qualcomm QSD8250 (ARMv7) with NEON (gcc Compiler Version 4.4.0) 1747 
Android 2.2 running on Qualcomm QSD8250 (ARMv7) with NEON (gcc Compiler Version 4.4.0) 2391 
Android 2.2 running on Qualcomm QSD8250 (ARMv7) with NEON (gcc Compiler Version 4.4.0) 2454 
Android 2.2 running on Qualcomm QSD8250 (ARMv7) without NEON (gcc Compiler Version 4.4.0) |1747 
Android 2.2 running on Qualcomm QSD8250 (ARMv7) without NEON (gcc Compiler Version 4.4.0) |2454 
Android 3.0 (gee Compiler Version 4.4.0) 2391 
Android 3.0 running on NVIDIA Tegra 250 T20 (ARMv7) (gcc Compiler Version 4.4.0) 1747 
Android 3.0 running on NVIDIA Tegra 250 T20 (ARMv7) (gcc Compiler Version 4.4.0) 2454 
Android 4.0 (gee Compiler Version 4.4.3) 2391 
Android 4.0 running on NVIDIA Tegra 250 T20 (ARMv7) (gcc Compiler Version 4.4.3) 1747 
Android 4.0 running on NVIDIA Tegra 250 T20 (ARMv7) (gcc Compiler Version 4.4.3) 2454 
Android 4.0 running on Qualcomm Snapdragon APQ8060 (ARMv7) with NEON (gcc compiler 1747 
Version 4.4.3) 

Android 4.0 running on Qualcomm Snapdragon APQ8060 (ARMv7) with NEON (gee compiler 2391 
Version 4.4.3) 

Android 4.0 running on Qualcomm Snapdragon APQ8060 (ARMv7) with NEON (gcc compiler 2454 
Version 4.4.3) 

Android 4.0 running on TI OMAP 3 (ARMv7) with NEON (gcc Compiler Version 4.4.3) 1747 
Android 4.0 running on TI OMAP 3 (ARMv7) with NEON (gcc Compiler Version 4.4.3) 2391 
Android 4.0 running on TI OMAP 3 (ARMv7) with NEON (gcc Compiler Version 4.4.3) 2454 
Android 4.1 running on TI DM3730 (ARMv7) (gcc Compiler Version 4.6) 2391 
Android 4.1 running on TI DM3730 (ARMv7) with NEON (gcc Complier Version 4.6) 1747 
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Platform Validation 
Android 4.1 running on TI DM3730 (ARMv7) with NEON (gcc Complier Version 4.6) 2391 
Android 4.1 running on TI DM3730 (ARMv7) with NEON (gcc Complier Version 4.6) 2454 
Android 4.1 running on TI DM3730 (ARMv7) without NEON (gcc Compiler Version 4.6) 1747 
Android 4.1 running on TI DM3730 (ARMv7) without NEON (gcc Compiler Version 4.6) 2454 
Android 4.2 running on Nvidia Tegra 3 (ARMv7) (gcc Compiler Version 4.6) 2391 
Android 4.2 running on Nvidia Tegra 3 (ARMv7) with NEON (gcc Compiler Version 4.6) 1747 
Android 4.2 running on Nvidia Tegra 3 (ARMv7) with Neon (gcc Compiler Version 4.6) 2391 
Android 4.2 running on Nvidia Tegra 3 (ARMv7) with NEON (gcc Compiler Version 4.6) 2454 
Android 4.2 running on Nvidia Tegra 3 (ARMv7) without NEON (gcc Compiler Version 4.6) 1747 
Android 4.2 running on Nvidia Tegra 3 (ARMv7) without NEON (gcc Compiler Version 4.6) 2454 
Android 5.0 32-bit running on Qualcomm APQ8084 (ARMv7) with NEON (gcc Compiler Version 1747 
4.9) 
Android 5.0 32-bit running on Qualcomm APQ8084 (ARMv7) with NEON (gcc Compiler Version 2398 
4.9) 
Android 5.0 32-bit running on Qualcomm APQ8084 (ARMv7) with NEON (gcc Compiler Version 2473 
4.9) 
Android 5.0 32-bit running on Qualcomm APQ8084 (ARMv7) with NEON (gcc Compiler Version 2575 
4.9) 
Android 5.0 32-bit running on Qualcomm APQ8084 (ARMv7) without NEON (gcc Compiler Version |1747 
4.9) 
Android 5.0 32-bit running on Qualcomm APQ8084 (ARMv7) without NEON (gcc Compiler Version |2398 
4.9) 
Android 5.0 32-bit running on Qualcomm APQ8084 (ARMv7) without NEON (gcc Compiler Version | 2473 
4.9) 
Android 5.0 32-bit running on Qualcomm APQ8084 (ARMv7) without NEON (gcc Compiler Version | 2575 
4.9) 
Android 5.0 64-bit running on SAMSUNG Exynos7420 (ARMv8) with NEON and Crypto Extensions | 1747 
(gcc Compiler Version 4.9) 
Android 5.0 64-bit running on SAMSUNG Exynos7420 (ARMv8) with NEON and Crypto Extensions |2398 
(gcc Compiler Version 4.9) 
Android 5.0 64-bit running on SAMSUNG Exynos7420 (ARMv8) with NEON and Crypto Extensions | 2473 
(gcc Compiler Version 4.9) 
Android 5.0 64-bit running on SAMSUNG Exynos7420 (ARMv8) with NEON and Crypto Extensions | 2575 
(gcc Compiler Version 4.9) 
Android 5.0 64-bit running on SAMSUNG Exynos7420 (ARMv8) without NEON and Crypto 1747 
Extensions (gcc Compiler Version 4.9) 
Android 5.0 64-bit running on SAMSUNG Exynos7420 (ARMv8) without NEON and Crypto 2398 
Extensions (gcc Compiler Version 4.9) 
Android 5.0 64-bit running on SAMSUNG Exynos7420 (ARMv8) without NEON and Crypto 2473 
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Extensions (gcc Compiler Version 4.9) 

Android 5.0 64-bit running on SAMSUNG Exynos7420 (ARMv8) without NEON and Crypto 2575 
Extensions (gcc Compiler Version 4.9) 

Apple iOS 5.0 running on ARM Cortex A8 (ARMv7) with NEON (gee Compiler Version 4.2.1) 1747 
Apple iOS 5.0 running on ARM Cortex A8 (ARMv7) with NEON (gcc Compiler Version 4.2.1) 2391 
Apple iOS 5.0 running on ARM Cortex A8 (ARMv7) with NEON (gee Compiler Version 4.2.1) 2454 
Apple iOS 5.1 (gcc Compiler Version 4.2.1) 2391 
Apple iOS 5.1 running on ARMv7 (gcc Compiler Version 4.2.1) 1747 
Apple iOS 5.1 running on ARMv7 (gcc Compiler Version 4.2.1) 2454 
Apple iOS 6.1 running on Apple A6X SoC (ARMv7s) (gee Compiler Version 4.2.1) 1747 
Apple iOS 6.1 running on Apple A6X SoC (ARMv7s) (gee Compiler Version 4.2.1) 2391 
Apple iOS 6.1 running on Apple A6X SoC (ARMv7s) (gee Compiler Version 4.2.1) 2454 
Apple iOS 7.1 64-bit running on Apple A7 (ARMv8) with NEON (clang Compiler Version 5.1) 1747 
Apple iOS 7.1 64-bit running on Apple A7 (ARMv8) with NEON (clang Compiler Version 5.1) 2454 
Apple iOS 7.1 64-bit running on Apple A7 (ARMv8) with NEON (clang Compiler Version 5.1) 2575 
Apple iOS 7.1 64- bit running on Apple A7 (ARMv8) without NEON (clang Compiler Version 5.1) 1747 
Apple iOS 7.1 64- bit running on Apple A7 (ARMv8) without NEON (clang Compiler Version 5.1) 2454 
Apple iOS 7.1 64- bit running on Apple A7 (ARMv8) without NEON (clang Compiler Version 5.1) 2575 
Apple OS X 10.7 running on Intel Core 17-3615QM (Apple LLVM version 4.2) 1747 
Apple OS X 10.7 running on Intel Core 17-3615QM (Apple LLVM version 4.2) 2391 
Apple OS X 10.7 running on Intel Core 17-3615QM (Apple LLVM version 4.2) 2454 
Apple OS X 10.7 running on Intel Core 17-3615QM (Apple LLVM version 4.2) 2575 
ArbOS 5.3 running on Xeon E5645 (x86) with AES-NI (gcc Compiler Version 4.1.2) 1747 
ArbOS 5.3 running on Xeon E5645 (x86) with AES-NI (gcc Compiler Version 4.1.2) 2391 
ArbOS 5.3 running on Xeon E5645 (x86) with AES-NI (gcc Compiler Version 4.1.2) 2454 
ArbOS 5.3 running on Xeon E5645 (x86) without AES-NI (gcc Compiler Version 4.1.2) 1747 
ArbOS 5.3 running on Xeon E5645 (x86) without AES-NI (gee Compiler Version 4.1.2) 2391 
ArbOS 5.3 running on Xeon E5645 (x86) without AES-NI (gcc Compiler Version 4.1.2) 2454 
CascadeOS 6.1 (32 bit) (gcc Compiler Version 4.4.5) 2391 
CascadeOS 6.1 (32 bit) running on Intel Pentium T4200 (gcc Compiler Version 4.4.5) 1747 
CascadeOS 6.1 (32 bit) running on Intel Pentium T4200 (gcc Compiler Version 4.4.5) 2454 
CascadeOS 6.1 (64 bit) (gcc Compiler Version 4.4.5) 2391 
CascadeOS 6.1 (64 bit) running on Intel Pentium T4200 (gcc Compiler Version 4.4.5) 1747 
CascadeOS 6.1 (64 bit) running on Intel Pentium T4200 (gcc Compiler Version 4.4.5) 2454 
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CentOS 5.6 64-bit running on Intel Xeon E5-2620v3 (gcc Compiler Version 4.1.2) 2391 
CentOS 5.6 64-bit running on Intel Xeon E5-2690v3 (gcc Compiler Version 4.1.2) 2391 
DataGravity Discovery Series OS V2.0 running on Intel Xeon E5-2420 (x86) with AES-NI (gcc 2398 
Compiler Version 4.7.2) 

DataGravity Discovery Series OS V2.0 running on Intel Xeon E5-2420 (x86) without AES-NI (gcc 2398 
Compiler Version 4.7.2) 

DSP Media Framework 1.4 running on TI C64x+ (TMS320C6x C/C++ Compiler v6.0.13) 1747 
DSP Media Framework 1.4 running on TI C64x+ (TMS320C6x C/C++ Compiler v6.0.13) 2454 
DSP Media Framework 1.4 (TMS320C6x C/C++ Compiler v6.0.13) 2391 
eCos 3 running on Freescale i.MX27 926ejs (ARMvSTEJ) (gcc Compiler Version 4.3.2) 1747 
eCos 3 running on Freescale 1.MX27 926ejs (ARMvSTEJ) (gcc Compiler Version 4.3.2) 2391 
eCos 3 running on Freescale i.MX27 926ejs (ARMvSTEJ) (gcc Compiler Version 4.3.2) 2454 
Fedora 14 running on Intel Core i5 with AES-NI (gee Compiler Version 4.5.1) 1747 
Fedora 14 running on Intel Core i5 with AES-NI (gcc Compiler Version 4.5.1) 2391 
Fedora 14 running on Intel Core 15 with AES-NI (gee Compiler Version 4.5.1) 2454 
Fedora 14 running on Intel Core 15 with AES-NI (gee Compiler Version 4.5.1) 2575 
FreeBSD 10.0 running on Xeon E5- 2430L (x86) with AES-NI (clang Compiler Version 3.3) 1747 
FreeBSD 10.0 running on Xeon E5-2430L (x86) with AES-NI (clang Compiler Version 3.3) 2391 
FreeBSD 10.0 running on Xeon E5- 2430L (x86) with AES-NI (clang Compiler Version 3.3) 2454 
FreeBSD 10.0 running on Xeon ES- 2430L (x86) with AES-NI (clang Compiler Version 3.3) 2575 
FreeBSD 10.0 running on Xeon E5-2430L (x86) without AES-NI (clang Compiler Version 3.3) 1747 
FreeBSD 10.0 running on Xeon E5-2430L (x86) without AES-NI (clang Compiler Version 3.3) 2391 
FreeBSD 10.0 running on Xeon E5-2430L (x86) without AES-NI (clang Compiler Version 3.3) 2454 
FreeBSD 10.0 running on Xeon E5-2430L (x86) without AES-NI (clang Compiler Version 3.3) 2575 
FreeBSD 10.2 running on Intel Xeon E5-2430L (x86) with AES-NI (clang Compiler Version 3.4.1) 2473 
FreeBSD 10.2 running on Intel Xeon E5-2430L (x86) without AES-NI (clang Compiler Version 3.4.1) | 2473 
FreeBSD 8.4 running on Intel Xeon E5440 (x86) 32-bit (gcc Compiler Version 4.2.1) 1747 
FreeBSD 8.4 running on Intel Xeon E5440 (x86) 32-bit (gee Compiler Version 4.2.1) 2391 
FreeBSD 8.4 running on Intel Xeon E5440 (x86) 32-bit (gcc Compiler Version 4.2.1) 2454 
FreeBSD 8.4 running on Intel Xeon E5440 (x86) without AESNI (gee Compiler Version 4.2.1) 1747 
FreeBSD 8.4 running on Intel Xeon E5440 (x86) without AES-NI (gcc Compiler Version 4.2.1) 2391 
FreeBSD 8.4 running on Intel Xeon E5440 (x86) without AESNI (gcc Compiler Version 4.2.1) 2454 
FreeBSD 9.1 running on Xeon E5-2430L (x86) with AES-NI (gcc Compiler Version 4.2.1) 1747 
FreeBSD 9.1 running on Xeon E5-2430L (x86) with AES-NI (gcc Compiler Version 4.2.1) 2391 
FreeBSD 9.1 running on Xeon E5-2430L (x86) with AES-NI (gcc Compiler Version 4.2.1) 2454 
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FreeBSD 9.1 running on Xeon E5-2430L (x86) without AESNI (gcc Compiler Version 4.2.1) 1747 
FreeBSD 9.1 running on Xeon E5-2430L (x86) without AES-NI (gcc Compiler Version 4.2.1) 2391 
FreeBSD 9.1 running on Xeon E5-2430L (x86) without AESNI (gcc Compiler Version 4.2.1) 2454 
FreeBSD 9.2 running on Xeon E5-2430L (x86) with AES-NI (gcc Compiler Version 4.2.1) 1747 
FreeBSD 9.2 running on Xeon E5-2430L (x86) with AES-NI (gcc Compiler Version 4.2.1) 2391 
FreeBSD 9.2 running on Xeon E5-2430L (x86) with AES-NI (gcc Compiler Version 4.2.1) 2454 
FreeBSD 9.2 running on Xeon E5-2430L (x86) without AES-NI (gcc Compiler Version 4.2.1) 1747 
FreeBSD 9.2 running on Xeon E5-2430L (x86) without AES-NI (gcc Compiler Version 4.2.1) 2391 
FreeBSD 9.2 running on Xeon E5-2430L (x86) without AES-NI (gcc Compiler Version 4.2.1) 2454 
HP-UX 111 (32 bit) (HP C/aC++ B3910B) 2391 
HP-UX 111 (32 bit) running on Intel Itanium 2 (HP C/aC++ B3910B) 1747 
HP-UX 111 (32 bit) running on Intel Itanium 2 (HP C/aC++ B3910B) 2454 
HP-UX 11i (64 bit) (HP C/aC++ B3910B) 2391 
HP-UX 111 (64 bit) running on Intel Itanium 2 (HP C/aC++ B3910B) 1747 
HP-UX 111 (64 bit) running on Intel Itanium 2 (HP C/aC++ B3910B) 2454 
iOS 6.0 running on Apple A5 / ARM Cortex-A9 (ARMv7) with NEON (gcc Compiler Version 4.2.1) |1747 
iOS 6.0 running on Apple A5 / ARM Cortex-A9 (ARMv7) with NEON (gee Compiler Version 4.2.1) |2391 
iOS 6.0 running on Apple A5 / ARM Cortex-A9 (ARMv7) with NEON (gee Compiler Version 4.2.1) |2454 
iOS 6.0 running on Apple A5 / ARM Cortex-A9 (ARMv7) without NEON (gcc Compiler Version 1747 
4.2.1) 
108 x running on Apple A5 / ARM Cortex-A9 (ARMv7) without NEON (gcc Compiler Version 2391 
4.2.1 
108 om running on Apple A5 / ARM Cortex-A9 (ARMv7) without NEON (gcc Compiler Version 2454 
4.2.1 
iOS 8.1 32-bit running on Apple A7 (ARMv8) with NEON (clang Compiler Version 600.0.56) 1747 
iOS 8.1 32bit running on Apple A7 (ARMv8) with NEON (clang Compiler Version 600.0.56) 2398 
iOS 8.1 32-bit running on Apple A7 (ARMv8) with NEON (clang Compiler Version 600.0.56) 2473 
iOS 8.1 32-bit running on Apple A7 (ARMv8) with NEON (clang Compiler Version 600.0.56) 2575 
iOS 8.1 32-bit running on Apple A7 (ARMv8) without NEON (clang Compiler Version 600.0.56) 1747 
iOS 8.1 32bit running on Apple A7 (ARMv8) without NEON (clang Compiler Version 600.0.56) 2398 
iOS 8.1 32-bit running on Apple A7 (ARMv8) without NEON (clang Compiler Version 600.0.56) 2473 
iOS 8.1 32-bit running on Apple A7 (ARMv8) without NEON (clang Compiler Version 600.0.56) 2575 
iOS 8.1 64-bit running on Apple A7 (ARMv8) with NEON and Crypto Extensions (clang Compiler 1747 
Version 600.0.56) 
iOS 8.1 64bit running on Apple A7 (ARMv8) with NEON and Crypto Extensions (clang Compiler 2398 


Version 600.0.56) 
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iOS 8.1 64-bit running on Apple A7 (ARMv8) with NEON and Crypto Extensions (clang Compiler 2473 
Version 600.0.56) 

iOS 8.1 64-bit running on Apple A7 (ARMv8) with NEON and Crypto Extensions (clang Compiler 2575 
Version 600.0.56) 

iOS 8.1 64bit running on Apple A7 (ARMv8) without NEON and Crypto Extensions (clang Compiler |2398 
Version 600.0.56) 

iOS 8.1 64-bit running on Apple A7 (ARMv8) without NEON and Crypto Extensions (clang Compiler |2473 
Version 600.0.56) 

iOS 8.1 64-bit running on Apple A7 (ARMv8) without NEON and Crypto Extensions (clang Compiler | 2575 
Version 600.0.56) 

iOS 8.1 64-bit running on Apple A7 (ARMv8) without NEON and Crypto Extensions (clang 1747 
Compilerv Version 600.0.56) 

Linux 2.6.27 (gee Compiler Version 4.2.4) 2391 
Linux 2.6.27 running on PowerPC e300c3 (gcc Compiler Version 4.2.4) 1747 
Linux 2.6.27 running on PowerPC e300c3 (gcc Compiler Version 4.2.4) 2454 
Linux 2.6.32 (gee Compiler Version 4.3.2) 2391 
Linux 2.6.32 running on TI AM3703CBP (ARMv7) (gcc Compiler Version 4.3.2) 1747 
Linux 2.6.32 running on TI AM3703CBP (ARMv7) (gee Compiler Version 4.3.2) 2454 
Linux 2.6.33 (gee Compiler Version 4.1.0) 2391 
Linux 2.6.33 running on PowerPC32 e300 (gcc Compiler Version 4.1.0) 1747 
Linux 2.6.33 running on PowerPC32 e300 (gcc Compiler Version 4.1.0) 2454 
Linux 2.6 (gcc Compiler Version 4.1.0) 2391 
Linux 2.6 (gcc Compiler Version 4.3.2) 2391 
Linux 2.6 running on a Nimble Storage CS300 with AES-NI 2422 
Linux 2.6 running on a Nimble Storage CS500 with AES-NI 2422 
Linux 2.6 running on a Nimble Storage CS700 with AES-NI 2422 
Linux 2.6 running on Broadcom BCM11107 (ARMv6) (gcc Compiler Version 4.3.2) 1747 
Linux 2.6 running on Broadcom BCM11107 (ARMv6) (gcc Compiler Version 4.3.2) 2454 
Linux 2.6 running on Freescale e500v2 (PPC) (gcc Compiler Version 4.4.1) 1747 
Linux 2.6 running on Freescale e500v2 (PPC) (gcc Compiler Version 4.4.1) 2391 
Linux 2.6 running on Freescale e500v2 (PPC) (gcc Compiler Version 4.4.1) 2454 
Linux 2.6 running on Freescale PowerPCe500 (gcc Compiler Version 4.1.0) 1747 
Linux 2.6 running on Freescale PowerPCe500 (gcc Compiler Version 4.1.0) 2454 
Linux 2.6 running on TI TMS320DM6446 (ARMv4) (gee Compiler Version 4.3.2) 1747 
Linux 2.6 running on TI TMS320DM6446 (ARMv4) (gcc Compiler Version 4.3.2) 2454 
Linux 3.10 32-bit running on Intel Atom E3845 (x86) with AES-NI (gcc Compiler Version 4.8.1) 2398 
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Linux 3.10 32-bit running on Intel Atom E3845 (x86) without AES-NI (gcc Compiler Version 4.8.1) |2398 
Linux 3.10 on VMware ESXi 6.00 running on Intel Xeon with AES-NI (gcc Compiler Version 4.8.3) 2631 
Linux 3.10 on Vmware ESXi 6.00 running on Intel Xeon without AES-NI (gee Compiler Version 2631 
4.8.3) 
Linux 3.10 running on Intel Xeon with AES-NI (gcc Compiler Version 4.8.3) 2631 
Linux 3.10 running on Intel Xeon without AES-NI (gcc Compiler Version 4.8.3) 2631 
Linux 3.4 64-bit under Citrix XenServer running on Intel Xeon E5-2430L (x86) without AES-NI 2422 
Linux 3.4 under Citrix XenServer 6.2 running on Intel Xeon E5-2430L with AES-NI (gcc Compiler 1747 
Version 4.8.0) 
Linux 3.4 under Citrix XenServer 6.2 running on Intel Xeon E5-2430L with AES-NI (gcc Compiler 2454 
Version 4.8.0) 
Linux 3.4 under Citrix XenServer 6.2 running on Intel Xeon E5-2430L with AES-NI (gcc Compiler 2575 
Version 4.8.0) 
Linux 3.4 under Citrix XenServer 6.2 running on Intel Xeon E5-2430L without AES-NI (gcc Compiler | 1747 
Version 4.8.0) 
Linux 3.4 under Citrix XenServer 6.2 running on Intel Xeon E5-2430L without AES-NI (gcc Compiler 2454 
Version 4.8.0) 
Linux 3.4 under Citrix XenServer 6.2 running on Intel Xeon E5-2430L without AES-NI (gcc Compiler | 2575 
Version 4.8.0) 
Linux 3.4 under Microsoft Windows 2012 Hyper-V running on Intel Xeon E5-2430L with AES-NI 1747 
(gcc Compiler Version 4.8.0)2 
Linux 3.4 under Microsoft Windows 2012 Hyper-V running on Intel Xeon E5-2430L with AES-NI 2454 
(gcc Compiler Version 4.8.0)2 
Linux 3.4 under Microsoft Windows 2012 Hyper-V running on Intel Xeon E5-2430L with AES-NI 2575 
(gcc Compiler Version 4.8.0) 
Linux 3.4 under Microsoft Windows 2012 Hyper-V running on Intel Xeon E5-2430L without AES-NI | 1747 
(gcc Compiler Version 4.8.0) 
Linux 3.4 under Microsoft Windows 2012 Hyper-V running on Intel Xeon E5-2430L without AES-NI |2454 
(gcc Compiler Version 4.8.0) 
Linux 3.4 under Microsoft Windows 2012 Hyper-V running on Intel Xeon E5-2430L without AES-NI |2575 
(gcc Compiler Version 4.8.0) 
Linux 3.4 under Vmware ESXi 5.1 running on Intel Xeon E5-2430L with AES-NI (gcc Compiler 1747 
Version 4.8.0) 
Linux 3.4 under Vmware ESXi 5.1 running on Intel Xeon E5-2430L with AES-NI (gcc Compiler 2454 
Version 4.8.0) 
Linux 3.4 under Vmware ESXi 5.1 running on Intel Xeon E5-2430L with AES-NI (gcc Compiler 2575 
Version 4.8.0) 
Linux 3.4 under Vmware ESXi 5.1 running on Intel Xeon E5-2430L without AES-NI (gcc Compiler |1747 
Version 4.8.0) 
Linux 3.4 under Vmware ESXi 5.1 running on Intel Xeon E5-2430L without AES-NI (gcc Compiler | 2454 
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Version 4.8.0) 

Linux 3.4 under Vmware ESXi 5.1 running on Intel Xeon E5-2430L without AES-NI (gcc Compiler |2575 
Version 4.8.0) 

Linux 3.8 running on ARM926 (ARMVSTEJ) (gcc Compiler Version 4.7.3) 1747 
Linux 3.8 running on ARM926 (ARMVSTEJ) (gcc Compiler Version 4.7.3) 2391 
Linux 3.8 running on ARM926 (ARMvSTEJ) (gcc Compiler Version 4.7.3) 2454 
Linux 3.8 running on ARM926 (ARMvSTEJ) (gcc Compiler Version 4.7.3) 2575 
Linux ORACLESP 2.6 running on ASPEED AST-Series (ARMv5) (gcc Compiler Version 4.4.5) 1747 
Linux ORACLESP 2.6 running on ASPEED AST-Series (ARMv5) (gcc Compiler Version 4.4.5) 2391 
Linux ORACLESP 2.6 running on ASPEED AST-Series (ARMv5) (gcc Compiler Version 4.4.5) 2454 
Linux ORACLESP 2.6 running on Emulex PILOT3 (ARMv5) (gcc Compiler Version 4.4.5) 1747 
Linux ORACLESP 2.6 running on Emulex PILOT3 (ARMv5) (gee Compiler Version 4.4.5) 2391 
Linux ORACLESP 2.6 running on Emulex PILOT3 (ARMv5) (gcc Compiler Version 4.4.5) 2454 
Microsoft Windows 7 (32 bit) (Microsoft 32 bit C/C++ Optimizing Compiler Version 16.00) 2391 
Microsoft Windows 7 (32 bit) running on Intel Celeron (Microsoft 32 bit C/C++ Optimizing Compiler |1747 
Version 16.00) 

Microsoft Windows 7 (32 bit) running on Intel Celeron (Microsoft 32 bit C/C++ Optimizing Compiler | 2454 
Version 16.00) 

Microsoft Windows 7 (32 bit) running on Intel Celeron (Microsoft 32 bit C/C++ Optimizing Compiler |2575 
Version 16.00) 

Microsoft Windows 7 (64 bit) (Microsoft C/C++ Optimizing Compiler Version 16.00) 2391 
Microsoft Windows 7 (64 bit) running on Intel Pentium 4 (Microsoft C/C++ Optimizing Compiler 1747 
Version 16.00) 

Microsoft Windows 7 (64 bit) running on Intel Pentium 4 (Microsoft C/C++ Optimizing Compiler 2454 
Version 16.00) 

Microsoft Windows 7 (64 bit) running on Intel Pentium 4 (Microsoft C/C++ Optimizing Compiler 2575 
Version 16.00) 

Microsoft Windows 7 running on Intel Core i5- 2430M (64-bit) with AES-NI (Microsoft ® C/C++ 1747 
Optimizing Compiler Version 16.00 for x64) 

Microsoft Windows 7 running on Intel Core 15-2430M (64-bit) with AES-NI (Microsoft « C/C++ 2391 
Optimizing Compiler Version 16.00 for x64) 

Microsoft Windows 7 running on Intel Core 15- 2430M (64-bit) with AES-NI (Microsoft ® C/C++ 2454 
Optimizing Compiler Version 16.00 for x64) 

Microsoft Windows 7 running on Intel Core i5- 2430M (64-bit) with AES-NI (Microsoft ® C/C++ 2575 
Optimizing Compiler Version 16.00 for x64) 

Microsoft Windows CE 5.0 (Microsoft C/C++ Optimizing Compiler Version 13.10 for ARM) 2391 
Microsoft Windows CE 5.0 running on ARMv7 (Microsoft C/C++ Optimizing Compiler Version 13.10 | 1747 


for ARM) 
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Microsoft Windows CE 5.0 running on ARMv7 (Microsoft C/C++ Optimizing Compiler Version 13.10 | 2454 
for ARM) 
Microsoft Windows CE 6.0 (Microsoft C/C++ Optimizing Compiler Version 15.00 for ARM) 2391 
Microsoft Windows CE 6.0 running on ARMvSTEJ (Microsoft C/C++ Optimizing Compiler Version | 1747 
15.00 for ARM) 
Microsoft Windows CE 6.0 running on ARMvSTEJ (Microsoft C/C++ Optimizing Compiler Version | 2454 
15.00 for ARM) 
Microsoft Windows Server 2008 R2 running on an Intel Xeon E5-2420 (x64) (Microsoft 32-bit C/C++ | 2454 
Optimizing Compiler Version 16.00.40219.01 for 80x86) 
NetBSD 5.1 (gcc Compiler Version 4.1.3) 2391 
NetBSD 5.1 running on Intel Xeon 5500 (gcc Compiler Version 4.1.3) 1747 
NetBSD 5.1 running on Intel Xeon 5500 (gcc Compiler Version 4.1.3) 2454 
NetBSD 5.1 running on PowerPCe500 (gcc Compiler Version 4.1.3) 1747 
NetBSD 5.1 running on PowerPCe500 (gcc Compiler Version 4.1.3) 2454 
OpenWRT 2.6 running on MIPS 24Kc (gcc Compiler Version 4.6.3) 1747 
OpenWRT 2.6 running on MIPS 24Kc (gcc Compiler Version 4.6.3) 2391 
OpenWRT 2.6 running on MIPS 24Kc (gcc Compiler Version 4.6.3) 2454 
Oracle Linux 5 (64 bit) (gcc Compiler Version 4.1.2) 2391 
Oracle Linux 5 (64 bit) running on Intel Xeon 5675 (gcc Compiler Version 4.1.2) 1747 
Oracle Linux 5 (64 bit) running on Intel Xeon 5675 (gcc Compiler Version 4.1.2) 2454 
Oracle Linux 5 running on Intel Xeon 5675 with AES-NI (gcc Compiler Version 4.1.2) 1747 
Oracle Linux 5 running on Intel Xeon 5675 with AES-NI (gcc Compiler Version 4.1.2) 2391 
Oracle Linux 5 running on Intel Xeon 5675 with AES-NI (gcc Compiler Version 4.1.2) 2454 
Oracle Linux 6 (gcc Compiler Version 4.4.6) 2391 
Oracle Linux 6 running on Intel Xeon 5675 with AES-NI (gcc Compiler Version 4.4.6) 1747 
Oracle Linux 6 running on Intel Xeon 5675 with AES-NI (gcc Compiler Version 4.4.6) 2391 
Oracle Linux 6 running on Intel Xeon 5675 with AES-NI (gcc Compiler Version 4.4.6) 2454 
Oracle Linux 6 running on Intel Xeon 5675 without AES-NI (gcc Compiler Version 4.4.6) 1747 
Oracle Linux 6 running on Intel Xeon 5675 without AES-NI (gcc Compiler Version 4.4.6) 2454 
Oracle Solaris 10 (32 bit) (gcc Compiler Version 3.4.3) 2391 
Oracle Solaris 10 (32 bit) running on SPARC-T3 (SPARCv9) (gcc Compiler Version3.4.3) 1747 
Oracle Solaris 10 (32 bit) running on SPARC-T3 (SPARCv9) (gcc Compiler Version3.4.3) 2454 
Oracle Solaris 10 (64 bit) (gcc Compiler Version 3.4.3) 2391 
Oracle Solaris 10 (64 bit) running on SPARC-T3 (SPARCv9) (gcc Compiler Version 3.4.3) 1747 
Oracle Solaris 10 (64 bit) running on SPARC-T3 (SPARCv9) (gcc Compiler Version 3.4.3) 2454 
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Oracle Solaris 11(32 bit) (gee Compiler Version 4.5.2) 2391 
Oracle Solaris 11 (32 bit) running on Intel Xeon 5675 (gee Compiler Version 4.5.2) 1747 
Oracle Solaris 11 (32 bit) running on Intel Xeon 5675 (gee Compiler Version 4.5.2) 2454 
Oracle Solaris 11 (32 bit) running on SPARC-T3 (SPARCv9) (Sun C Version 5.12) 1747 
Oracle Solaris 11 (32 bit) running on SPARC-T3 (SPARCv9) (Sun C Version 5.12) 2454 
Oracle Solaris 11 (32 bit) (Sun C Version 5.12) 2391 
Oracle Solaris 11 (64 bit) (gee Compiler Version 4.5.2) 2391 
Oracle Solaris 11 (64 bit) running on Intel Xeon 5675 (gcc Compiler Version 4.5.2) 1747 
Oracle Solaris 11 (64 bit) running on Intel Xeon 5675 (gcc Compiler Version 4.5.2) 2454 
Oracle Solaris 11 (64 bit) running on SPARC-T3 (SPARCv9) (Sun C Version 5.12) 1747 
Oracle Solaris 11 (64 bit) running on SPARC-T3 (SPARCv9) (Sun C Version 5.12) 2454 
Oracle Solaris 11 (64 bit) (Sun C Version 5.12) 2391 
Oracle Solaris 11 running on Intel Xeon 5675 with AESNI (32 bit) (gcc Compiler Version 4.5.2) 1747 
Oracle Solaris 11 running on Intel Xeon 5675 with AES-NI (32 bit) (gcc Compiler Version 4.5.2) 2391 
Oracle Solaris 11 running on Intel Xeon 5675 with AESNI (32 bit) (gcc Compiler Version 4.5.2) 2454 
Oracle Solaris 11 running on Intel Xeon 5675 with AESNI (64 bit) (gcc Compiler Version 4.5.2) 1747 
Oracle Solaris 11 running on Intel Xeon 5675 with AES-NI (64 bit) (gcc Compiler Version 4.5.2) 2391 
Oracle Solaris 11 running on Intel Xeon 5675 with AESNI (64 bit) (gcc Compiler Version 4.5.2) 2454 
PexOS 1.0 under vSphere ESXi 5.1 running on Intel Xeon E52430L with AES-NI (gcc Compiler 1747 
Version 4.6.3)3 

PexOS 1.0 under vSphere ESXi 5.1 running on Intel Xeon E52430L with AES-NI (gcc Compiler 2454 
Version 4.6.3)3 

PexOS 1.0 under vSphere ESXi 5.1 running on Intel Xeon E52430L without AES-NI (gcc Compiler 1747 
Version 4.6.3) 

PexOS 1.0 under vSphere ESXi 5.1 running on Intel Xeon E52430L without AES-NI (gcc Compiler |2454 
Version 4.6.3) 

QNX 6.4 running on Freescale i.MX25 (ARMv4) (gee Compiler Version 4.3.3) 1747 
QNX 6.4 running on Freescale i. MX25 (ARMv4) (gee Compiler Version 4.3.3) 2391 
QNX 6.4 running on Freescale i.MX25 (ARMv4) (gee Compiler Version 4.3.3) 2454 
QNX 6.5 running on Freescale i.MX25 (ARMv4) (gee Compiler Version 4.3.3) 1747 
QNX 6.5 running on Freescale i.MX25 (ARMv4) (gcc Compiler Version 4.3.3) 2391 
QNX 6.5 running on Freescale i.MX25 (ARMv4) (gee Compiler Version 4.3.3) 2454 
TS-Linux 2.4 running on Arm920Tid (ARMv4) (gee Compiler Version 4.3.2) 2398 
TS-Linux 2.4 running on Arm920Tid (ARMv4) (gee Compiler Version 4.3.2) 2473 
TS-Linux 2.4 running on Arm920Tid (ARMv4) (gcc Compiler Version 4.3.2)4 1747 
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Platform Validation 
Ubuntu 10.04 (32 bit) (gee Compiler Version 4.1.3) 2391 
Ubuntu 10.04 (32 bit) running on Intel Pentium T4200 (gcc Compiler Version 4.1.3) 1747 
Ubuntu 10.04 (32 bit) running on Intel Pentium T4200 (gcc Compiler Version 4.1.3) 2454 
Ubuntu 10.04 (64 bit) (gee Compiler Version 4.1.3) 2391 
Ubuntu 10.04 (64 bit) running on Intel Pentium T4200 (gcc Compiler Version 4.1.3) 1747 
Ubuntu 10.04 (64 bit) running on Intel Pentium T4200 (gcc Compiler Version 4.1.3) 2454 
Ubuntu 10.04 running on Intel Core i5 with AES-NI (32 bit) (gcc Compiler Version 4.1.3) 1747 
Ubuntu 10.04 running on Intel Core 15 with AES-NI (32 bit) (gcc Compiler Version 4.1.3) 2391 
Ubuntu 10.04 running on Intel Core i5 with AES-NI (32 bit) (gcc Compiler Version 4.1.3) 2454 
Ubuntu 10.04 running on Intel Pentium T4200 (gcc Compiler Version 4.1.3) 1747 
Ubuntu 10.04 running on Intel Pentium T4200 (gcc Compiler Version 4.1.3) 2454 
Ubuntu 12.04 running on Intel Xeon E5-2430L (x86) with AES-NI (gcc Compiler Version 4.6.3) 2398 
Ubuntu 12.04 running on Intel Xeon E5-2430L (x86) without AES-NI (gee Compiler Version 4.6.3) |2398 
Ubuntu 13.04 running on AM335x Cortex-A8 (ARMv7) (gcc Compiler Version 4.7.3) 2391 
Ubuntu 13.04 running on AM335x Cortex-A8 (ARMv7) with NEON (gcc Compiler Version 4.7.3) 1747 
Ubuntu 13.04 running on AM335x Cortex-A8 (ARMv7) with NEON (gcc Compiler Version 4.7.3) 2391 
Ubuntu 13.04 running on AM335x Cortex-A8 (ARMv7) with NEON (gcc Compiler Version 4.7.3) 2454 
Ubuntu 13.04 running on AM335x Cortex-A8 (ARMv7) with NEON (gcc Compiler Version 4.7.3) 2575 
Ubuntu 13.04 running on AM335x Cortex-A8 (ARMv7) without NEON (gcc Compiler Version 4.7.3) 11747 
Ubuntu 13.04 running on AM335x Cortex-A8 (ARMv7) without NEON (gcc Compiler Version 4.7.3) |2454 
Ubuntu 13.04 running on AM335x Cortex-A8 (ARMv7) without NEON (gcc Compiler Version 4.7.3) |2575 
uCLinux 0.9.29 (gcc Compiler Version 4.2.1) 2391 
uCLinux 0.9.29 running on ARM 922T (ARMv4) (gcc Compiler Version 4.2.1) 1747 
uCLinux 0.9.29 running on ARM 922T (ARMv4) (gcc Compiler Version 4.2.1) 2454 
Vmware Horizon Workspace 1.5 under Vmware ESXi 5.0 running on Intel Xeon E3-1220 (x86) with | 1747 
AES-NI (gcc Compiler Version 4.5.1)1 
Vmware Horizon Workspace 1.5 under Vmware ESXi 5.0 running on Intel Xeon E3-1220 (x86) with |2454 
AES-NI (gcc Compiler Version 4.5.1)1 
Vmware Horizon Workspace 1.5 under Vmware ESXi 5.0 running on Intel Xeon E3-1220 (x86) 1747 
without AES-NI (gcc Compiler Version 4.5.1) 
Vmware Horizon Workspace 1.5 under Vmware ESXi 5.0 running on Intel Xeon E3-1220 (x86) 2454 
without AES-NI (gcc Compiler Version 4.5.1) 
Vmware Horizon Workspace 2.1 under vSphere ESXi 5.5 running on Intel Xeon E3-1220 (x86) with | 1747 
AES-NI (gcc Compiler Version 4.5.1) 
Vmware Horizon Workspace 2.1 under vSphere ESXi 5.5 running on Intel Xeon E3-1220 (x86) with |2391 


AESNI (gcc Compiler Version 4.5.1) 


Page 43 of 225 


User Guide - OpenSSL FIPS Object Module v2.0 


Platform Validation 
Vmware Horizon Workspace 2.1 under vSphere ESXi 5.5 running on Intel Xeon E3-1220 (x86) with | 2454 
AES-NI (gee Compiler Version 4.5.1) 
Vmware Horizon Workspace 2.1 under vSphere ESXi 5.5 running on Intel Xeon E3-1220 (x86) 1747 
without AES-NI (gcc Compiler Version 4.5.1) 
Vmware Horizon Workspace 2.1 under vSphere ESXi 5.5 running on Intel Xeon E3-1220 (x86) 2391 
without AES-NI (gcc Compiler Version 4.5.1) 
Vmware Horizon Workspace 2.1 under vSphere ESXi 5.5 running on Intel Xeon E3-1220 (x86) 2454 
without AES-NI (gcc Compiler Version 4.5.1) 
VxWorks 6.7 running on Intel Core 2 Duo (x86) (gcc Compiler Version 4.1.2) 2398 
VxWorks 6.8 (gcc Compiler Version 4.1.2) 2391 
VxWorks 6.8 running on TI TNETV1050 (MIPS) (gee Compiler Version 4.1.2) 1747 
VxWorks 6.8 running on TI TNETV1050 (MIPS) (gee Compiler Version 4.1.2) 2454 
VxWorks 6.9 running on Freescale P2020 (PPC) (gcc Compiler Version 4.3.3) 1747 
VxWorks 6.9 running on Freescale P2020 (PPC) (gcc Compiler Version 4.3.3) 2398 
VxWorks 6.9 running on Freescale P2020 (PPC) (gee Compiler Version 4.3.3) 2473 
Windows Embedded Compact 7 running on Freescale 1.MX53xA (ARMv7) with NEON (Microsoft 1747 
C/C++ Optimizing Compiler Version 15.00.20720) 
Windows Embedded Compact 7 running on Freescale i.MX53xA (ARMv7) with NEON (Microsoft 2391 
C/C++ Optimizing Compiler Version 15.00.20720) 
Windows Embedded Compact 7 running on Freescale 1.MX53xA (ARMv7) with NEON (Microsoft 2454 
C/C++ Optimizing Compiler Version 15.00.20720) 
Windows Embedded Compact 7 running on Freescale i.MX53xD (ARMv7) with NEON (Microsoft 1747 
C/C++ Optimizing Compiler Version 15.00.20720) 
Windows Embedded Compact 7 running on Freescale 1.MX53xD (ARMv7) with NEON (Microsoft 2391 
C/C++ Optimizing Compiler Version 15.00.20720) 
Windows Embedded Compact 7 running on Freescale i.MX53xD (ARMv7) with NEON (Microsoft 2454 


C/C++ Optimizing Compiler Version 15.00.20720) 


Table 2.10b 


Page 44 of 225 


User Guide - OpenSSL FIPS Object Module v2.0 


3. Compatible Platforms 


The FIPS Object Module is designed to run on a wide range of hardware and software platforms. 
Any computing platform that meets the conditions in the Security Policy can be used to host a FIPS 
140-2 validated FIPS Object Module provided that module is generated in accordance with the 
Security Policy. 


At the time the OpenSSL FIPS Object Module v2.0 was developed, all Unix*"*-like environments 
supported by the full OpenSSL distribution were also supported by the FIPS validated source files 
included in the FIPS Object Module. However, successful compilation of the FIPS Object Module 
for all such platforms was not verified. If any platform specific compilation errors occur that can 
only be corrected by modification of the FIPS distribution files (see Appendix B of the Security 
Policy), then the FIPS Object Module will not be validated for that platform. 


It is also noted that a platform which is currently supported (but untested) may not be supported in 
the future as revisions are made to the FIPS validated sources. For example, a change made for one 
platform may adversely affect another, untested platform. 


By default, the FIPS Object Module software utilizes assembly language optimizations for some 
supported platforms. Currently assembler language code residing within the cryptographic module 
boundary is used for the x86/Intel*'” ELF and ARM*' machine architectures. The FIPS Object 
Module build process will automatically select and include these assembly routines by default 
when building on a x86 platform. The assembly language code was included in the validation 
testing, so a FIPS Object Module built using the x86/Intel® assembly language routines will result 
in a FIPS 140-2 validated Object Module. Assembly Language and Optimizations are discussed in 
detail in Section 3.2.3 Assembler Optimizations. 


3.1 Build Environment Requirements 


The platform portability of the FIPS Object Module source code is contingent on several basic 
assumptions about the build environment: 


1. The environment is either a) “Unix*-like” with a make command and a 1d command with 
a “—r” (or “-i”) option, or Microsoft Windows. 


Creation of the monolithic FIPS Object Module fipscanister.o requires a linker 
capable of merging several object modules into one. This requirement is known to be a 
problem with VMS and some older versions of LD. EXE under Windows®. 


UNIX is a registered trademark of The Open Group 
"Intel is a registered trademark of the Intel Corporation 
BARM is a trademark of ARM Limited. 
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2. The compiler is required to place variables declared with the const qualifier in a read-only 
segment. This behavior is true of almost all modern compilers. If the compiler fails to do 
so the condition will be detected at run-time and the in-core hashing integrity check will 
fail. 


3. The platform supports execution of compiled code on the build system (i.e. build host and 
target are binary compatible); or an appropriate "incore" utility is available to calculate the 
digest from the on-disk resident object code. See further discussion of cross-compilation in 
83.4. 


4. Cross-compilation uses a technique for determining the integrity check digest that may not 
work for all cross-compilation environments, so each such new environment must be 
analyzed for suitability. See further discussion of cross-compilation in 83.4. 


3.2 Known Supported Platforms 


The generation of a monolithic object module and the in-core hashing integrity test have been 
verified to work with both static and shared builds on the following platforms (note the . /config 
“shared” option is forbidden by the terms of the validation when building a FIPS validated 
module, but the fipscanister.o object module can be used in a shared library!”). Note a 
successful build of the FIPS module may be possible on other platforms; only the following were 
explicitly tested as of the date this document was last updated: 


Androide” on ARMv7?! 32 bit 

Androide on ARMv7 with NEON 32 bit 
HP-UXe?, on IA64 with 32 and 64 bit 
Linux&? on ARMv6, ARMv7 32 bit 

Linux on x86-64 32 and 64 bit 

Linux on x86-64 32 with SSE2 and 64 bit 
Linux on x86-64 with AES-NI 32 and 64 bit 
Linux on PowerPC? 

Solaris®* on x86-64 with 32 and 64 bit 
Solaris® on SPARCv9?5 with 32 and 64 bit 
Solaris& on x86-64 with SSE2 32 and 64 bit 
Windows® on x86-64 with SSE2 32 and 64 bit 


PA convenient way of generating a shared library containing fipscanister.o is discussed in Appendix B 
Android is a trademark of Google Inc. 

“ARM, is a trademark or registered trademark of ARM Ltd or its subsidiaries. 

?HP-UX is a registered trademark of Hewlett-Packard Company. 

Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. 

“PowerPC is a trademark of International Business Machines Corporation in the United States, other countries, or 
both. 

Solaris is a registered trademark of Oracle and/or its affiliates. 

?5SPARCQ is a registered trademark of SPARC International, Inc. 
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uClinuxe” on ARMv4 

VxWorks® on MIPSe”” 

DSP Media Framework 1.4 on TI&? C64x+ 
Apple&?! iOS® on ARMv7 

Windows CE on ARMv7 

NetBSD” on PowerPC 

NetBSD on x86-64 


Among the platforms known to not be supported are Windows on x86-64 with AES-NI, VMS&?, 


Mac OS Xe", 
Platform Cross Reference 
Operating System | Android 2.2, 4.0 
3, HP-UX 11i 
Linux 2.6 
Solaris 10 
Solaris 11 
Windows 7 
uCLinux 0.9 
VxWorks 6.8 
Windows CE 
NetBSD 
Processor 
y 
Apple A6 (ARMv7 and ARMv7s) 
Apple A5 (ARMv6 and ARMv7) 
ARMv4 v 
ARMv6 v 


"'uClinux is a registered trademark of Arcturus Networks Inc. 

?*Vx Works is a registered trademarks of Wind River Systems, Inc. 

?MIPS is a trademark or registered trademark of MIPS Technologies, Inc. in the United States and other countries. 
*°TI is a registered trademark of Texas Instruments Incorporated 

? Apple and iOS are registered trademarks of Apple Inc. 

PNetBSD® is a registered trademark of The NetBSD Foundation, Inc. 

VMS is a registered trademark of Digital Equipment Corporation. 

“Mac OS X is a registered trademark of Apple, Inc. 
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Platform Cross Reference 


ARMv7 v v 


ARMv7 NEON v 


IA64 32 bit v 


IA64 64 bit v 


MIPS v 


PowerPC v 


SPARCv9 32 bit v v 


SPARCv9 64 bit v v 


x86-64 32 bit 


x86-64 64 bit 


x86-64 SSE2 32 bit v 


x86-64 SSE2 64 bit v 


x86-64 AES-NI 32 bit 


NESSUS 
S SISINS& S 


x86-64 AES-NI 64 bit 


Table 3.2 


A commonly asked question is "does this validation extend to my specific platform X"? For 
instance: “is use of the Module validated on CentOS x86-64 when CentOS was not formally tested 
but Fedora was?" Or “is use with Linux kernel 2.6.35 validated when only 2.6.33 was formally 
tested?" Unfortunately there is no hard and fast answer to such questions. 


Based on extensive discussions over the years we have developed some informal rules of thumb to 
determine when a given target platform corresponds with a formally tested platform (Operational 
Environment) 


Important Disclaimer 


Only the CMVP can provide authoritative answers to questions 
about FIPS 140-2. The following discussion represents the un- 
enlightened and non-authoritative opinions of persons and 
institutions lacking any official standing to interpret the meaning or 
intent of FIPS 140-2 or the validation process. CMVP guidance 
always takes precedence over any statements in this document. 


Rules of thumb: 
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1. Does the target system "code path" (see following section) correspond with that of a 
formally tested platform? 


2. Do any run-time selectable optimizations (see section 83.2.3) correspond with those of a 
formally tested platform? 


3. Will a binary module that builds and runs on one of the formally tested platforms (or was 
built on the build-time system for a formally tested cross-compiled platform) run as-is on 
the target system? 


4. Does the processor "core" (ARMv6 versus ARMv7, for instance) correspond to that of a 
formally tested platform? Here the consideration is ABI compatibility -- two processors 
which can interchangeably execute the same set of machine instructions are effectively 
equivalent. 


5. Does the "major" OS version (e.g. Solaris 10 versus Solaris 11) correspond to that of a 
formally tested platform? The "major" version is generally taken to be the full revision 
label for OS's using only one or two "dot" levels (e.g., Android 2.2 or Solaris 10, 11), and 
the first two "dot" levels for OS's using more than two "dot" levels (e.g., Linux 2.6.37, 
uCLinux 0.9.29)”. 


If the answer to all of these questions is "yes" then -- in general — the prospective target platform 
can in general be reasonably considered as equivalent to a formally tested platform. 


Arguments based on apparent "common sense" considerations should be used cautiously where 
FIPS 140-2 is concerned, but where general purpose validated software modules are concerned a 
little thought shows that strict insistence on an exact match between target platforms and formally 
tested Operational Environments would make it effectively impossible to widely deploy validated 
software through most enterprises. For instance, one of the formally tested platforms was "Android 
2.2.20.A995" on an " ARMv7 rev 2 v71" processor. If a formally tested platform had to correspond 
at that level of detail then provision of validated modules would be very difficult, as the extensive 
amount of time required to obtain a FIPS 140-2 validation means that the specific platform used for 
testing will be updated or obsolete by the time the validation is completed. 


The role of the compiler used for building the validated Module has never been fully delineated. 
The general — and unofficial — consensus of the FIPS 140-2 user and test lab communities appears 
to be that the precise version of the compiler need not correspond exactly with that used for the 
generation of the formally tested Module (for instance, gcc 4.4.1 versus 4.4.7). 


If a review determines that no formally tested platform corresponds to the target platform of 
interest, there are several options: 


Note this rule of thumb has implications for the recent and more or less arbitrary jump of the Linux kernel version 
number from 2.6.x to 3.0.x. 


Page 49 of 225 


User Guide - OpenSSL FIPS Object Module v2.0 


1. Vendor or user "affirmation" per section G.5 of the Implementation Guidance document 
(Reference 3). This topic is discussed in more detail in 85.5. 


2. A “change letter" modification to extend an existing validation to include the platform of 
interest. The change letter process can often be performed in a few weeks with a price tag 
in the low five figures, as opposed to the many months and high five figure to low six figure 
price tag of a conventional full validation. 


3. Afull validation leveraging the source code and documentation from the OpenSSL FIPS 
Object Module validation. Such a "private label" validation will still take many months but 
is typically much less expensive than an unrelated validation. An advantage of the "private 
label" validation is that upon formally engaging an accredited test lab the vendor becomes 
eligible?? to have the prospective module listed on the "Modules In Process" list” 
(http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140InProcess.pdf). The presence 
of a vendor module on that list is a sufficient condition for completion of many procurement 
actions in the U.S. Department of Defense and federal government. 


3.2.1 Code Paths and Command Sets 


For the purposes of the validation testing a “platform” is a unique combination of source code and 
the specific build-time options used to turn that source code into binary code. The build-time 
inclusion of assembler optimizations effectively changes the source code, and source code 
selections vary based on the target architecture word size of 32 or 64 bits. 


Due to budget and schedule constraints only some assembler optimizations for ARM and x86-64 
were tested, so only those optimizations are available for building the FIPS Object Module. Two 
separate sets of source code were identified to cover plain C (no assembler) for x86-64 Linux 32 
and 64 bits. 


Even though the same source code is used for both Linux/Unix and Windows operating systems, 
the build instructions are sufficiently unique to each of the two OS families that the decision was 


made to test each code path for both OS families. 


The resulting test cases can be represented in the following tables: 


Code Path Command Set Representative Platform 
Linux/Unix Windows Linux/Unix Windows 
pure C 32 bit Ul WI ul wl 


Strictly speaking the test lab must also be in possession of drafts of all required documentation. In the case of private 
label validations closely modeled on an OpenSSL FIPS Object Module validation that is readily accomplished, usually 
before the formal contract with the test lab is executed. 

The "Module in Process" list is often referred to as the "pre-val" list. 
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Code Path Command Set Representative Platform 
Linux/Unix Windows Linux/Unix Windows 
pure C 64 bit U2 W2 ul w2 
x86 assembler U3 W3 u2 w3 
x86-64 assembler U4 W4 u2 w4 


Table 3.2.1a - Code Paths and Command Sets 


where the command sets are 


Command Set Name 


Build Commands 


Ul 


Linux/Unix, pure C 


make 


make install 


./config no-asm 


U2 


Linux/Unix with x86/x86-64 
optimizations 


./config 
make 


make install 


WI 


Windows, pure C 


ms\do_fips 


no-asm 


W2 


Windows with x86/x86-64 optimizations |ms\do_fips 


3.2.Ib - Command Sets 


The actual representative systems tested for the validation were: 


Generic System 


Actual System 


OS - Processor - Optimization 


Android 2.2 on ARMv7 with 
NEON 


Desire) 


Android 2.2 (HTC Qualcomm QSD 8250 (ARMv7) NEON 


Android 2.2 on ARMv7 with 
NEON 


Desire) 


Android 2.2 (HTC Qualcomm QSD 8250 (ARMv7) NEON 


2 Android 2.2 on ARMv7 Android 2.2 (Dell Qualcomm QSD 8250 (ARMv7) None 
Streak) 

3 Windows x86 32 bit Microsoft Windows 7 | Intel Celeron (x86) None 
32 bit 

4 uCLinux on ARMv4 uClinux 0.9.29 ARM 922T (ARMv4) None 
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Generic System 


Actual System 


OS - Processor - Optimization 


5 Linux 2.6 on x86 with AES-NI |Fedora 14 Intel Core 15 (x86) AES-NI 
64 bit 
6 HP-UX 11 on 1464 32 bit HP-UX 11i (hpux- Intel Itanium 2 (1464) None 
1a64-cc, 32 bit mode) 
7 HP-UX 11 on 1464 64 bit HP-UX 111 (hpux64- | Intel Itanium 2 (1464) None 
1364-cc, 64 bit mode) 
8 Linux on x86 32bit Ubuntu 10.04 Intel Pentium T4200 (x86) None 
9 Android 2.2 on ARMv7 Android 2.2 NVIDIA Tegra 250 T20 (ARMv7) | None 
(duplicate of platform 2) (Motorola Xoom) 
10 Linux 2.6 on PPC Linux 2.6.27 PowerPC e300c3 (PPC) None 
11 Windows on x86 64 bit Microsoft Windows 7 | Intel Pentium 4 (x86) None 
64 bit 
12 Linux 2.6 on x86 with AES-NI | Ubuntu 10.04 32 bit | Intel Core 15 (x86) AES-NI 
32 bit 
13 Linux 2.6 on PPC (duplicate of | Linux 2.6.33 PowerPC32 e300 (PPC) None 
platform 10) 
16 Android 2.2 on ARMv7 with | Android 2.2 OMAP 3530 (ARMv7) NEON 
NEON (duplicate of platform 
1) 
17 C64x+ DSP DSP Media TI C64x+ None 
Framework 1.4 
19 VxWorks 6.8 on MIPS VxWorks 6.8 TITNETV1050 (MIPS) None 
20 Linux 2.6 on ARMv6 Linux 2.6 Broadcom BCM11107 (ARMv6) | None 
21 Linux 2.6 on ARMv7 Linux 2.6 TI TMS320DM6446 (ARMv4) None 
22 Linux 2.6 on ARMv7 Linux 2.6.32 TI AM3703CBP (ARMv7) None 
23 Solaris 10 on SPARCv9 32 bit | Solaris 10 32bit SPARC-T3 (SPARCv9) None 
24 Solaris 10 on SPARCv9 32 bit | Solaris 10 64bit SPARC-T3 (SPARCv9) None 
25 Solaris 11 on x86-64 32 bit Solaris 11 32bit Intel Xeon 5260 (x86) None 
26 Solaris 11 on x86-64 64 bit Solaris 11 64bit Intel Xeon 5260 (x86) None 
27 Solaris 11 on x86-64 with Solaris 11 32bit Intel Xeon 5260 (x86) AES-NI 


AES-NI 32 bit 
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Generic System 


Actual System 


OS - Processor - Optimization 


28 Solaris 11 on x86-64 with Solaris 11 64bit Intel Xeon 5260 (x86) AES-NI 
AES-NI 64 bit 
29 hoe Linux 5 on x86-64 64 |Oracle Linux 5 64bit | Intel Xeon 5260 (x86) None 
It 
30 CascadeOS 6.1 3 on x86 32 bit | CascadeOS 6.1 32bit | Intel Pentium T4200 (x86) None 
31 CascadeOS 6.1 3 on x86 64 bit | CascadeOS 6.1 64bit | Intel Pentium T4200 (x86) None 
32 Linux 2.6 on x86-64 32 bit Ubuntu 10.04 32bit | Intel Pentium T4200 (x86) None 
33 Linux 2.6 on x86-64 64 bit Ubuntu 10.04 64bit — | Intel Pentium T4200 (x86) None 
34 Oracle Linux 5 on x86-64 with | Oracle Linux 5 Intel Xeon 5675 (x86) AES-NI 
AES-NI 
35 Oracle Linux 6 on x86-64 Oracle Linux 6 Intel Xeon 5675 (x86) None 
36 Oracle Linux 6 on x86-64 with | Oracle Linux 6 Intel Xeon 5675 (x86) AES-NI 
AES-NI 
37 Solaris 11 32bit on SPARCv9 Solaris 11 32bit SPARC-T3 (SPARCv9) None 
38 Solaris 11 64bit on SPARCv9 Solaris 11 64bit SPARC-T3 (SPARCv9) None 
39 Android 4.0 on ARMv7 Android 4.0 NVIDIA Tegra 250 T20 None 
(Motorola Xoom) 
40 Linux 2.6 on PPC Linux 2.6 Freescale PowerPC-e500 None 
41 Apple iOS 5.1 on ARMv7 Apple iOS 5.1 ARMv7 None 
42 WinCE 6.0 on ARMVSTEJ WinCE 6.0 ARMVSTEJ None 
43 WinCE 5.0 on ARMv7 WinCE 5.0 ARMv7 None 
44 Android 4.0 on ARMv7 Android 4.0 OMAP3 NEON 
45 NetBSD 5.1 on PPC NetBSD 5.1 PowerPC-e500 None 
46 NetBSD 5.1 on x86-64 NetBSD 5.1 Intel Xeon 5500 (x86) None 
47 Windows 2008 32-bit under Windows 2008 Xeon E3-1220v2 (x86) None 
vSphere on x86-64 
48 Windows 2008 64-bit under Windows 2008 Xeon E3-1220v2 (x86) None 
vSphere on x86-64 
49 RHEL 6 32-bit on x86-64 RHEL 6 Xeon E3-1220v2 (x86) None 
50 RHEL 6 64-bit on x86-64 RHEL 6 Xeon E3-1220v2 (x86) None 
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Generic System 


Actual System 


OS - Processor - Optimization 


51 Windows 7 64-bit on x86-64 Windows 7 Intel Core 15-2430M (x86) AES-NI 
with AES-NI 
52 Android 4.1 on ARMv7 Android 4.1 TI DM3730 (ARMv7) None 
53 Android 4.1 on ARMv7 with | Android 4.1 TI DM3730 (ARMv7) NEON 
NEON 
54 Android 4.2 on ARMv7 Android 4.2 Nvidia Tegra 3 (ARMv7) None 
55 Android 4.2 on ARMv7 with | Android 4.2 Nvidia Tegra 3 (ARMv7) NEON 
NEON 
56 Windows Embedded Compact | Windows Embedded | Freescale 1.MX53xA (ARMv7) NEON 
7 on ARMv7 with NEON Compact 7 
57 Windows Embedded Compact | Windows Embedded | Freescale i. MX53xA (ARMv7) NEON 
7 on ARMv7 with NEON Compact 7 
58 Android 4.0 on ARMv7 with | Android 4.0 Qualcomm Snapdragon APQ8060 | NEON 
NEON 
(ARMv7) 
59 VMware Horizon Mobile 1.3 | VMware Horizon Qualcomm MSM8X60 (ARMv7) | NEON 
under VMware under Android | Mobile 1.3 under 
4.0 on ARMv7 with NEON VMware under 
Android 4.0 
60 Apple OS X 10.7 on x86-64 Apple OS X 10.7 Intel Core 17-3615QM (x86) None 
61 Apple iOS 5.0 on ARMv7 with | Apple iOS 5.0 ARM Cortex A8 (ARMv7) NEON 
NEON 
62 OpenWRT 2.6 on MIPS OpenWRT 2.6 MIPS 24Kc None 
63 QNX 6.4 on ARMv4 QNX 6.4 Freescale .MX25 (ARMv4) None 
64 Apple iOS 6.1 on ARMv7s Apple iOS 6.1 Apple A6X SoC (ARMv7s) None 
65 eCos 3 on ARMvSTEJ eCos 3 Freescale 1.M X27 926ejs None 
(ARMvSTEJ) 
66 VMware Horizon Workspace | VMware Horizon Intel Xeon E3-1220 (x86) None 
1.5 under vSphere on x86-64 | Workspace 1.5 under 
vSphere 
67 VMware Horizon Workspace VMware Horizon Intel Xeon E3-1220 (x86) AES-NI 
1.5 under vSphere on x86-64 Workspace 1.5 under 
with AES-NI vSphere 
68 Ubuntu 13.04 on ARMv7 Ubuntu 13.04 AM335x Cortex-A8 (ARMv7) None 
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Generic System 


Actual System 


OS - Processor - Optimization 


69 Ubuntu 13.04 on ARMv7 with | Ubuntu 13.04 AM335x Cortex-A8 (ARMv7) NEON 
NEON 

70 Linux 3.8 on ARMvSTEJ Linux 3.8 ARM926 (ARMVSTEJ) None 

71 Linux 3.4 under Citrix Linux 3.4 under Intel Xeon E5-2430L (x86) None 
XenServer on x86-64 Citrix XenServer 

72 Linux 3.4 under Citrix Linux 3.4 under Intel Xeon E5-2430L (x86) AES-NI 
XenServer on x86-64 with Citrix XenServer 
AES-NI 

73 Linux 3.4 under VMware ESX | Linux 3.4 under Intel Xeon E5-2430L (x86) None 
on x86-64 VMware ESX 

74 Linux 3.4 under VMware ESX || Linux 3.4 under Intel Xeon E5-2430L (x86) AES-NI 
on x86-64 with AES-NI VMware ESX 

75 Linux 3.4 under Microsoft Linux 3.4 under Intel Xeon E5-2430L (x86) None 
Hyper-V on x86-64 Microsoft Hyper-V 

76 Linux 3.4 under Microsoft Linux 3.4 under Intel Xeon E5-2430L (x86) AES-NI 
Hyper-V on x86-64 with AES- | Microsoft Hyper-V 
NI 

77 Apple iOS 6.0 on ARMv7 Apple iOS 6.0 Apple A5 / ARM Cortex-A9 None 

(ARMv7) 

78 Apple iOS 6.0 on ARMv7 with | Apple iOS 6.0 Apple A5 / ARM Cortex-A9 NEON 
NEON (ARMv7) 

79 PexOS 1.0 under vSphere on |PexOS 1.0 under Intel Xeon E5-2430L (x86) None 
x86-64 vSphere 

80 PexOS 1.0 under vSphere on | PexOS 1.0 under Intel Xeon E5-2430L (x86) AES-NI 
x86-64 with AES-NI vSphere 

81 Linux 2.6 on PPC Linux 2.6 Freescale e500v2 (PPC) None 

82 AcanOS 1.0 on x86-64 AcanOS 1.0 ntel Core 17-3612QE (x86) None 

83 AcanOS 1.0 on x86-64 with AcanOS 1.0 Intel Core 17-3612QE (x86) AES-NI 
AES-NI 

84 AcanOS 1.0 on ARMv5 AcanOS 1.0 Intel Core 17-3612QE (x86) None 

85 FreeBSD 8.4 on x86-64 FreeBSD 8.4 Intel Xeon E5440 (x86) None 

86 FreeBSD 9.1 on x86-64 FreeBSD 9.1 Xeon E5-2430L (x86) None 
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Generic System Actual System 
OS - Processor - Optimization 

87 FreeBSD 9.1 on x86-64 with | FreeBSD 9.1 Xeon E5-2430L (x86) AES-NI 
AES-NI 

88 ArbOS 5.3 on x86-64 ArbOS 5.3 Xeon E5645 (x86) None 

89 ArbOS 5.3 on x86-64 with ArbOS 5.3 Xeon E5645 (x86) AES-NI 
AES-NI 

90 Linux ORACLESP 2.6 on Linux ORACLESP | ASPEED AST-Series (ARMv5) None 
ARMv5 2.6 

91 Linux ORACLESP 2.6 on Linux ORACLESP |Emulex PILOT 3 (ARMv5) None 
ARMv5 2.6 

92 FreeBSD 9.2 on x86-64 FreeBSD 9.2 Xeon E5-2430L (x86) None 

93 FreeBSD 9.2 on x86-64 with | FreeBSD 9.2 Xeon E5-2430L (x86) AES-NI 
AES-NI 

94 FreeBSD 10.0 on x86-64 FreeBSD 10.0 Xeon E5-2430L (x86) None 

95 FreeBSD 10.0 on x86-64 with |FreeBSD 10.0 Xeon E5-2430L (x86) AEs-NI 
AES-NI 

96 

97 

98 

99 

100 


Table 3.2.1c - Representative Systems 


3.2.2 32 versus 64 Bit Architectures 


Many 64 bit platforms provide backward compatible support for 32 bit code via hardware or 


software emulation. Software built on a 32 bit version of a specific operating system will generally 


run as-is on the equivalent 64 bit version of that operating system. Software built on a 64 bit 
operating system can be either 32 bit or 64 bit code depending on vendor build environment 


defaults and explicit build time options. Any such 64 bit code will not run on a 32 bit equivalent 
operating system, so care must be taken when compiling code for distribution to both 32 and 64 bit 
systems. 


By default the FIPS Object Module build process will generate 64 bit code on 64 bit systems. 
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Since the command sets included in the validation testing do not permit the explicit specification of 
the compile time options that would otherwise be used to specify the generation of 32 or 64 bit 
code, it may be necessary for some platforms to build a 32 bit FIPS Object Module on a 32 bit 
system, and conversely for 64 bit. 


It is also possible on most 64-bit platforms to install a 32-bit build environment which would be 
supported. Details as to how to configure such an environment are beyond the scope of this 
document. 


3.2.3 Assembler Optimizations 


The only option for processor architectures other than x86/x86-64 and ARM is to use the pure C 
language implementation and not any of the hand-coded performance optimized assembler as each 
assembler implementation requires separate FIPS testing. For example, an Itanium or PowerPC 
system can only build and use the pure C language module. 


For the x86/x86-64 and ARM processors several levels of optimization are supported by the code. 
Note that most such optimizations, if compiled into executable code, are selectively enabled at 
runtime depending on the capabilities of the target processor. If the Module is built and executed 
on the same platform (the build-time and run-time systems are the same) then the appropriate 
optimization will automatically be utilized (assuming that the build+target system corresponds to a 
formally tested platform). 


For x86-64 there are three possible optimization levels: 

1. No optimization (plain C) 

2: SSE2 optimization 

3. AES-NI+PCLMULQDQ+SSSE3 optimization 
Note that other theoretically possible combinations (e.g. AES-NI only, or SSE3 only) are not 
addressed individually, so that a processor which does not support all three of AES-NI, 
PCLMULQDQ, and SSSE3 will fall back to only SSE2 optimization. 


The runtime environment variable OPENSSL _ia32cap=~0x200000200000000 disables use of 
AES-NI, PCLMULQDQ, and SSSE3 optimizations for x86-64. 


For ARM there are two possible optimization levels: 


l. Without NEON 
2. With NEON (ARM7 only) 


The runtime variable OPENSSL_armcap=0 disables use of NEON optimizations for ARM. 
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If all optimization levels have not been formally tested for a given platform, care must be taken to 
verify that the optimizations enabled at run-time on any target systems correspond to a formally 
tested platform. For instance, if "Windows on x86 32-bit" was formally tested but "Windows on 
x86 with AES-NI 32-bit" was not” then the Module would be validated when executed on a non- 
AES-NI capable target processor, but would not be validated when executed on an AES-NI capable 
system. Note the processor optimization capabilities will often not be obvious to administrators or 
end users installing software. 


When the target platforms are not known to have capabilities corresponding to tested platforms 
then the risk of inadvertently utilizing the unvalidated optimizations at run-time can can be avoided 
by setting the appropriate environment variables at run-time”: 


Disabling run-time selectable optimizations 
Platform Environment Variable Value 
x86/x86-64 OPENSSL ia32cap —0x200000200000000 
ARM OPENSSL armcap 0 


3.3 Creation of Shared Libraries 


The FIPS Object Module is not directly usable as a shared library, but it can be linked into an 
application that is a shared library. A *FIPS compatible" OpenSSL distribution will automatically 
incorporate an available FIPS Object Module into the liberypto shared library when built using 
the fips option (see 84.2.3). 


3.4 Cross-compilation 


Compilers and linkers are separate programs which work together to generate object code for a 
target system. They are also programs composed of object code that is executed on the build 
system. When the build and target systems are the same we say the process is referred to as a 
"native" build; when they are different it is referred to as a "cross-compilation" build. 


Many compilers and linkers (or build environments containing compilers and linkers) are capable 
of creating object code for multiple target platforms. For the case of the native build the 
./config command” automatically determines the target system from the characteristics of the 
build system. This determination is made by setting a series of variables that are used to select an 


"This was the case as of the initial OpenSSL FIPS Object Module 2.0 validation, though such platforms may be added 
by subsequent modifications. 

An alternative is to sponsor the addition of the unsupported platform optimization to the validated Module 
“Microsoft Windows platforms are handled somewhat differently and are discussed elsewhere. 
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arbitrary architecture label defined in the . /Configure command that is invoked by 
./config. This architecture label can be displayed with the "—t" command line option: 


$ ./config -t 

Operating system: i686-whatever-linux2 

Configuring for linux-elf 

/usr/bin/perl ./Configure linux-elf -march-pentium -Wa,-- 
noexecstack 


$ 


In this example the architecture target is "linux-elf" and the . /Configure command will be 
invoked with the additional arguments "-march=pentium -Wa,--noexecstack ". 


This implicit determination of the target architecture can be overridden by manually specifying the 
appropriate environment variables. This explicit determination is optional and unnecessary for 
native builds, but required for cross-compilation. A typical example is shown here for cross- 
compilation for the Android ARM target platform: 


#!/bin/sh 


# Edit 
export 
# Edit 
export 


this to wherever you unpacked the NDK 
ANDROID NDK-"$PWD" 

to wherever you put incore script 
FIPS SIG="$PWD/incore” 


# Shouldn't need to edit anything past here. 
PATH-S$ANDROID NDK/android-ndk-r4b/build/prebuilt/linux- 
x86/arm-eabi-4.4.0/bin:$PATH ; export PATH 


export 
export 
export 
export 
export 
export 


MACHINE=armv71 

RELEASE=2.6.32.GMU 

SYSTEM=android 

ARCH=arm 

CROSS_COMPILE="arm-eabi-" 

ANDROID DEV="S$ANDROID NDK/android-ndk- 


r4b/build/platforms/android-8/arch-arm/usr" 


export 


HOSTCC=gee 


With those environment variables specified on a Linux x86 system the . /config now selects a 
different target architecture: 


$ ./config -t 
Operating system: armv71l-whatever-android 
Configuring for android-armv7 
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/usr/bin/perl ./Configure android-armv7 -Wa,--noexecstack 


$ 


When building using cross-compilation a different technique must be used to determine the 
embedded integrity check digest value. For native builds an interim executable is created and 
executed to calculate this digest from live memory, in the same way that the digest is calculated at 
runtime during the POST integrity test. When cross-compiling that technique cannot be used 
because the cross-compiled executables cannot (in general) be run on the build host. 


Instead of building and executing an interim executable, a special purpose utility is used to 
calculate the digest by examining the cross-compiled object code as it resides on disk. One such 
utility, incore, is provided to handle ELF formats. Even though this utility is effectively platform 
neutral on most Linux-like operating systems , the process as a whole is not designed to work with 
arbitrary ELF code and can be relied on only for explicitly verified cross-compile cases as reflected 
in fips/fips canister.c. Accommodation of new cross-compilation targets is likely to be trivial but 
will still require separate validation. 


Thus, although the incore utility is theoretically capable of handling arbitrary ELF binary code 
(native or not), it is not used in non-cross-compile/native cases. Cross-compiled non-ELF 
platforms would require different utilities and separate validation. 


In general the C compiler is required to segregate constant data in a contiguous area (e.g. by placing 
it in a dedicated segment) to compile the FIPS module. Some compilers were found to fail to meet 
the const data segment requirement. In the cases where the errant behavior was observed, the 
compiler was instructed to generate position-independent code*!. 


In such cases it might be possible to rectify the problem by defining the _ fips constseg macro in 
fips/fipssyms.h and harmonizing that definition with declaration of FIPS rodata start and 

FIPS rodata end in fips/fips canister.c. Unfortunately, such an approach will require a separate 
FIPS 140-2 validation, however. 


“The primary reason for compiling the FIPS 2.0 module with -fPIC is for versatility, so that the fipscanister object 
module will be usable in either the context of a statically-linked application or dynamic library. Use of non-PIC code 
is inappropriate in a dynamic library, but linking PIC statically was proven to work on all tested platforms. Thus, 
where such versatility is not of interest then -/PIC could be dropped to target statically-linked applications only. A 
separate validation will be required, of course. 
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4. Generating the FIPS Object Module 


This section describes the creation of a FIPS Object Module for subsequent use by an application. 
The Security Policy provides procedures for acquiring, verifying, building, installing, protecting, 
and initializing the FIPS Object Module. In case of discrepancies between the User Guide and the 
Security Policy, the Security Policy should be used. 


Finally, recall from Section 2.4.2, Object Module (Link Time) Integrity, that applications link 
against liberypto.so or libcrypto. a, and not directly to fipscanister.o. 


4.1 Delivery of Source Code 


The OpenSSL FIPS Object Module software is only available in source format. The specific source 
code distributions can be found at http://www.openssl.org/source/*”. as files with names of the form 
openssl-fip-2.0.N.tar.gz where the revision number N reflects successive extensions of the FIPS 
Object Module to support additional platforms: 


http: //www.openssl.org/source/openssl-fips-2.0.tar.gZ 
http://www.openssl.org/source/openssl-fips-2.0.1.tar.gz 
http://www.openssl.org/source/openssl-fips-2.0.2.tar.gz 


The latest revision will be suitable for all tested platforms, whereas earlier revisions will work only 
for the platforms tested as of that revision. 


The CMVP introduced significant new requirements for verification of the 2.0 source code 
distribution. This requirement is discussed in more detail in 84.1.3; but in summary, it can no 
longer be downloaded and used as before. A "trusted path" must be used for transfer of the source 


code distribution. 
OpenSSL 


At present the one method known to satisfy the "trusted path" requirement is 
obtain the source code distribution from the vendor of record (OVS) on 
physical media (CD). For instructions on requesting this CD see 


http://openssl.com/fips/verify.html. opensS FPS je ho v2.0 


OpenSSL Software Foundation, Inc. 


The OpenSSL FIPS Object Module software was delivered to the FIPS 140-2 

testing laboratory in source form as this complete OpenSSL distribution, and was built by the 
testing laboratory using the standard build procedure as described in the Security Policy document 
and reproduced below and in Appendix B. 


“Closely related distributions lacking binary curve ECC, opensl-fips-ecp-2.0.N.tar.gz, are also available; see 86.5. 
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For each of the openss1-fips-2.0.N.tar.gz distributions there is also a distribution file 

with the name of the form openssl-fips-ecp-2.0.N.tar.gz. These "ecp" distributions 
are the same as the corresponding 2.0.N distributions with binary curve ECC omitted (see Section 
6.5). 


Note: OVS recommends that the downloaded tarballs be considered untrusted for any purpose until 
verified as described in $4.1.2. 


4.1.1 Creation of a FIPS Object Module from Other Source Code 


Many OpenSSL distributions other than the specific distributions used for the validation can be 
used to build a fipscanister.o object using undocumented build-time options. The reader is 
reminded that any such object code cannot be used or represented as FIPS 140-2 validated. The 
Security Policy document is very clear on that point. 


4.1.2 Verifying Integrity of Distribution (Best Practice) 


This step is optional and not mandated by the FIPS140-2 validation. It is also not recognized as 
having any value by the CMVP, but is considered a best practice by the OpenSSL team for all 
software downloads from OpenSSL. 


The integrity and authenticity of the complete OpenSSL distribution should be validated manually 
with the PGP signatures“ published by the OpenSSL team with the distributions 
(ftp://ftp.openssl.org/source/) to guard against a corrupted source distribution. Note this check is 
separate and distinct from the CMVP mandated FIPS 140-2 source file integrity check ($4.1.3). 


The PGP signatures are contained in the file 
openssl-fips-2.0.tar.gz.asc 


This digital signature of the distribution file can be verified against the OpenSSL PGP public key 
by using the PGP or GPG applications (GPG can be obtained free of charge from 
http://www.gnupg.org/)". This validation consists of confirming that the distribution was signed by 
a known trusted key as identified in Appendix A, “OpenSSL Distribution Signing Keys". 


First, find out which key was used to sign the distribution. Any of several different valid keys may 
have been used for this purpose. The "hexadecimal key id", an identifier used for locating keys on 
the keystore servers, is displayed when attempting to verify the distribution. If the signing key is 
not already in your keyring the hexadecimal key id of the unknown key will still be displayed: 


$ gpg openssl-1.0.1z.tar.gz.asc 
gpg: Signature made Tue Sep 30 09:00:37 2009 using RSA key ID 49A563D9 
gpg: Can't check signature: public key not found 
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Example 4.1.2a - Find Id of Signing Key 


In this example the key id is Ox49A563D9. Next see if this key id belongs to one of the OpenSSL 
core team members authorized to sign distributions. The authorized keys are listed in Appendix A. 


Note that some older versions of gpg will not display the key id of an unknown public key; either 
upgrade to a newer version or load all of the authorized keys. 


If the hexadecimal key id matches one of the known valid OpenSSL core team keys then download 
and import the key. 


PGP keys can be downloaded interactively from a keyserver web interface or directly by the pgp or 
gpg commands. 


The hexadecimal key id of the team member key (for example, the search string "0x49A563D9" 
can be used to download the OpenSSL PGP key from a public keyserver 

(http: //www.keyserver.net/, http://pgp.mit.edu, or others). Keys can be downloaded interactively to 
an intermediate file or directly by the pgp or gpg program. 


Once downloaded to an intermediate file, markcox.key in this example, the key can be imported 
with the command: 


$ gpg --import markcox.key 

gPg: key 49A563D9: public key "Mark Cox <mjc@redhat.com>" imported 
gpg: Total number processed: 1 

gpg: imported: 1 (RSA: 1) 

$ 


Example 4.1.2b - Importing a Key from a Downloaded file 


These examples assume the pgp or gpg software is installed. The key may also be imported 
directly into your keyring: 


$ gpg --keyserver pgp.mit.edu --recv-key 49a563d9 

gpg: key 49A563D9: public key "Mark Cox <mjc@redhat.com>" imported 
gpg: Total number processed: 1 

gpg: imported: 1 (RSA: 1) 


Example 4.1.2c - PGP Key Import 


Note that at this point we have not yet established that the key is authentic or that the distribution 
was signed with that key; a key that might be authentic has been obtained in a form where it can be 
utilized for further validation. 
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To verify that the distribution file was signed by the imported key use the pgp or gpg command 
with the signature file as the argument, with the distribution file also present in the same directory: 


$ gpg /work/build/openssl/openssl-1.0.1.tar.gz.asc 
gpg: Signature made Tue Sep 30 09:00:37 2009 using RSA key ID 49A563D9 
gpg: Good signature from "Mark Cox <mjc@redhat.com>" 


gpg: aka "Mark Cox <mark@awe.com>" 

gpg: aka "Mark Cox <mark@c2.net>" 

gpg: aka "Mark Cox <mcox@c2.net>" 

gpg: aka "Mark Cox <mark@ukweb.com>" 

gpg: aka "Mark Cox <mjc@apache.org>" 

gpg: WARNING: This key is not certified with a trusted signature! 

gpg: There is no indication that the signature belongs to the owner. 


Primary key fingerprint: 7B 79 19 FA 71 6B 87 25 OE 77 21 E5 52 D9 83 BF 
$ 


Example 4.1.2d - PGP File Signature Verification 


In this example the validity of the file signature with respect to the key was verified. That is, the 
target file openssl-fips-2.0.tar.gz was signed by the key with id 494563D9. The 
warning message in this example is alerting the key is not part of the "web of trust", a relational 
ranking system based on manually assigned confidence levels. Instead of relying on the web of 
trust which will differ from one user to another, the key should be matched directly to a list of 
known valid keys. 


The final step of verification is to establish that the signing key is authentic. To do so, confirm the 
key fingerprint of the key which signed the distribution is one of the valid OpenSSL core team keys 
listed in Appendix A, “OpenSSL Distribution Signing Keys”. In this example, 7B 79 19 FA 71 6B 
87 25 OE 77 21 E5 52 D9 83 BF is in fact authentic according to Appendix A. 

4.1.3 Verifying Integrity of the Full Distribution for the FIPS Object Module 


IMPORTANT NOTE: This step has changed from prior validations, and is required 
per the OpenSSL Security Policy! 


The validation now includes a requirement for “secure installation.” In practice that means the 
distribution file should be obtained directly from the vendor (OVS) on physical media. A more 
complete discussion of this requirement including the elaborate steps needed when the distribution 
is not obtained on physical media can be found in §6.6. 


Physical media can be requested from OVS at: 
OpenSSL Validation Services, Inc. 


1829 Mount Ephraim Road 
Adamstown, MD 21710 
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USA 
(+1 301-874-2447) 


verifycd@openssl.com 


An E-mail containing the full postal address is the preferred point of contact. It is our intention to 
provide these CDs at no cost as long as we are able. We ask that you only request this CD if you 
plan to use it for generation of FIPS 140-2 validated cryptography in a context that requires such 
compliance. For any other purposes the downloaded files are bit-for-bit identical and will generate 
exactly the same results. 


The simpler verification requirement for prior OpenSSL FIPS Object Module validations, namely: 


The HMAC-SHA-1 digest of the distribution file is published in Appendix B of the 
Security Policy. The Security Policy can be found at NIST, 


http://csrc.nist.gov/groups/STM/emvp/documents/140-1/140sp/140sp105 1 .pdf. 


This digest should be calculated and compared against the published value, as in: 
$ env OPENSSL FIPS-1 openssl shal -hmac etaonrishdlcupfm openssl-fips-2.0.tar.gz 


where the openss1 command is from a recent version of OpenSSL that supports the 
-hmac option?. If you don't have the openss1 command yet it will be generated by 
the build process. 


is now specifically disallowed. With the new requirement use of the openss1 command, even 
from another version of the OpenSSL FIPS Object Module, is no longer permitted as in general it 
will not have been obtained via a "secure installation". 


4.2 Building and Installing the FIPS Object Module with OpenSSL 
(Unix/Linux) 


Due to significant differences in the two basic operating system families, Unix®/Linux® and 
Microsoft® Windows® platforms are discussed separately. Instructions for Windows® are given in 
$4.3. In addition, a Mac OS X example is offered at E.1 Apple OS X Support; and an iOS example 
is given in Error: Reference source not found. 


4.2.1 Building the FIPS Object Module from Source 


Next build the FIPS Object Module from source. The FIPS 140-2 validation specific code is 
incorporated into the resulting FIPS Object Module when the fips configuration option is 


“The OPENSSL FIPS-1 environment variable will enable FIPS mode for an openss1 command built from a FIPS 
capable OpenSSL distribution. 
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specified. Per the conditions of the FIPS 140-2 validation only two configuration commands may 
be used: 


./config 
Or 
./config no-asm 


where the specific option used depends on the platform (see $3.2. 1). Note that “fips canister” is 
implied, so there is no need for either ./config fipscanisterbuild or ./config fips. 


The environment variable FIPSDIR, if present, points to the pathname of the location where the 
validated module will be installed. This location defaults to /usr/local/ssl/fips-2.0. 


The specification of any other options on the command line, such as 
./config shared 


is not permitted. Note that in the case of the “shared” option position independent code is 
generated by default so the generated FIPS Object Module can be included in a shared library“. 


Note that as a condition of the FIPS 140-2 validation no other user specified configuration options 
may be specified. This restriction means that an optional install prefix cannot be specified — 
however, there is no restriction on subsequent manual relocation of the generated files to the 
desired final location. 


Then: 
make 


to generate the FIPS Object Module file fipscanister.o, the digest for the FIPS Object 
Module file, fipscanister.o.shal, and the source file used to generate the embedded digest, 
fips premain.c. The fipscanister.o, fipscanister.o.shal, and 

fips premain.c files are intermediate files (i.e., used in the generation of an application but 
not referenced by that application at runtime). The object code in the fipscanister.o file is 
incorporated into the runtime executable application at the time the binary executable is generated. 


This should also be obvious, but modifications to any of the intermediate files generated by the 

*. /config" or “make” commands are not permitted. If the original distribution is modified, or 
if anything other than those three specified commands are used, or if any intermediate files are 
modified, the result is not FIPS validated. 


“If not for the FIPS validation prohibition, on most but not all platforms the “shared” option could safely be chosen 
regardless of the intended use. See Appendix E for one known exception. 
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4.2.2 Installing and Protecting the FIPS Object Module 


The system administrator should install the generated fipscanister.o, 
fipscanister.o.shal, and fips premain.c files in a location protected by the host 
operating system security features. These protections should allow write access only to authorized 
system administrators (FIPS 140-2 Crypto Officers) and read access only to authorized users. 


For Unix? based or Linux? systems this protection usually takes the form of root ownership and 
permissions of 0755 or less for those files and all parent directories. When all system users are not 
also authorized users the world (public) read and execute permissions should be removed from 
these files. 


The usual 
make install 


will install the fipscanister.o, fipscanister.o.shal, fips premain.c, and 
fips premain.c.shal files in the target location (typically /usr/local/ssl/fips- 
2.0/1ib/ for Unix? based or Linux? systems, or as specified by the FIPSDIR environment 
variable) with the appropriate permissions to satisfy the security requirement. These four files 
constitute the validated FIPS Object Module; the other files also installed by this command are not 
validated. Note that it is also permissible to install these files in other locations by other means, 
provided that they are protected with appropriate permissions as noted above: 


cp fipscanister.o fipscanister.o.shal <target-directory> 
cp fips premain.c fips premain.c.shal <target-directory> 


Note that fipscanister.o can either be statically linked into an application binary executable, 
or statically linked into a shared library. 


4.2.3 Building a FIPS Capable OpenSSL 


Once the validated FIPS Object Module has been generated it is usually combined with an 
OpenSSL distribution in order to provide the standard OpenSSL API. Any 1.0.1 or 1.0.2 release 
can be used for this purpose. The commands 


./config fips <...other options...> 


make <...options...> 
make install 
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will build and install the new OpenSSL without overwriting the validated FIPS Object Module 
files. The FIPSDIR environment variable or the --with-fipsdir command line option can 
be used to explicitly reference the location of the FIPS Object Module (fipscanister.o). 


The combination of the validated FIPS Object Module plus an OpenSSL distribution built in this 
way is referred to as a FIPS capable OpenSSL, as it can be used either as a drop-in replacement for 
a non-FIPS OpenSSL or for use in generating FIPS mode applications. 


Note that a standard OpenSSL distribution built for use with the FIPS Object Module must have the 
./config fips option specified. Other configuration options may be specified in addition to 


fips, but omission of the fips option will cause errors when using the OpenSSL libraries with 
the FIPS Object Module. 


4.3 Building and Installing the FIPS Object Module with OpenSSL 
(Windows) 


The build procedure for Windows is similar to that for the regular OpenSSL product, using MSVC 
and NASM for compilation. Note MASM is not supported. 


The second stage uses VC++ to link OpenSSL 1.0.1 or 1.0.2 against the installed FIPS module, to 
obtain the complete FIPS capable OpenSSL. Both static and shared libraries are supported. 


4.3.1 Building the FIPS Object Module from Source 
Build the FIPS Object Module from source: 
ms\do fips [no-asm] 
where the no-asm option may or may not be present depending on the platform (see $3.2. 1). 


Note that as a condition of the FIPS 140-2 validation no other user specified configuration options 
may be specified. 


4.3.2 Installing and Protecting the FIPS Object Module 


The system administrator should install the generated fipscanister.lib, 
fipscanister.lib.shal,and fips premain.c files in a location protected by the host 
operating system security features. These protections should allow write access only to authorized 
system administrators (FIPS 140-2 Crypto Officers) and read access only to authorized users. 
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For Microsoft® Windows® based systems this protection can be provided by ACLs limiting write 
access to the administrator group. When all system users are not authorized users the Everyone 
(public) read and execute permissions should be removed from these files. 


4.3.3 Building a FIPS Capable OpenSSL 


The final stage is VC++ compilation of a standard OpenSSL distribution to be referenced in 
conjunction with the previously built and installed FIPS Object Module. 


Download an OpenSSL 1.0.1 or 1.0.2 distribution. Follow the standard Windows* build procedure 
except that instead of the command: 


perl Configure VC-WIN32 
do: 
perl Configure VC-WIN32 fips --with-fipsdir=c:\fips\path 


where "c: \ fips \path" is wherever the FIPS module from the first stage was installed. Static 
and shared library builds are supported. 


This command is followed by the usual 

ms\do_nasm 
and 

nmake -f ms\ntdll.mak 
to build the shared libraries only, or 

nmake -f ms\nt.mak 
to build the OpenSSL static libraries. The standard OpenSSL build with the fips option will use a 
base address for libeay32.d11 of 0xFB00000 by default. This value was chosen because it is 
unlikely to conflict with other dynamically loaded libraries. In the event of a clash with another 
dynamically loaded library which will trigger runtime relocation of Libeay32 .d11, the integrity 


check will fail with the error 


FIPS R FINGERPRINT DOES NOT MATCH NONPIC RELOCATED 


A base address conflict can be resolved by shuffling the other DLLs or re-compiling OpenSSL with 
an alternative base address specified with the --with-baseaddr= option. 
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Note that the developer can identify which DLLs are relocated with the Process Explorer utility 
from http: //www.microsoft.com/technet/sysinternals/ProcessesAndThreads/ProcessExplorer.mspx. 


The resulting FIPS capable OpenSSL can be used for shared or static linking. The shared library 
built (when ms \ntd11 .mak is used as the Makefile) links fipscanister. lib into 


libeay32.dl1 using fipslink.pl in accordance with the requirements of the Security 
Policy. 
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5. Creating Applications Which Reference the FIPS Object 
Module 


Only minor modifications are needed to adapt most applications that currently use OpenSSL for 
cryptography to use the FIPS capable OpenSSL with the FIPS Object Module. The checklist in 
Figure 4 summarizes the modifications which are covered in more detail in the following 
discussion: 


a Use the FIPS Object Module for all cryptography 

a Initialize FIPS mode with FIPS_mode_set () 

a Generate application executable object with embedded FIPS 
Object Module digest 

a Protect critical security parameters 


Figure 4 - Application Checklist 


Appendix C contains a simple but complete sample application utilizing the FIPS Object Module 
with OpenSSL as described in this section. 


5.1 Exclusive Use of the FIPS Object Module for Cryptography 


In order for the referencing application to claim FIPS 140-2 validation, all cryptographic functions 
utilized by the application must be provided exclusively by the FIPS Object Module. The 
OpenSSL API used in conjunction with the FIPS Object Module in FIPS mode is designed to 
automatically disable all non-FIPS cryptographic algorithms. 


5.2 FIPS Mode Initialization 


Somewhere very early in the execution of the application FIPS mode must be enabled. This should 
be done by invocation of the FIPS_mode_set () function call, either directly or indirectly as in 
these following examples. 


Note that it is permitted to not enable FIPS mode, in which case OpenSSL should function as it 
always has. The application will not, of course, be operating in validated mode. 


The FIPS mode set() function call when invoked with any positive argument will enable the FIPS 
mode of operation. Depending on the argument it may also enable additional restrictions. For 
example, an argument of 1 will enable the basic FIPS mode where all FIPS approved algorithms are 
available. An argument of FIPS SUITEB (2) will restrict the available algorithms to those 
allowed by the Suite B specification. 


Option 1: Direct call to FIPS mode set() 
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#ifdef OPENSSL FIPS 
if(options.no fips <= 0) 
{ 
if(!FIPS mode set (1) ) 
{ 
ERR load crypto strings(); 
ERR print errors fp(stderr); 
exit (1); 

) 
else 
fprintf(stderr,"*** IN FIPS MODE ***\n"); 
) 
fendif 


Example 5.2a — Direct Invocation of FIPS mode set() 


Option 2: Indirect call via OPENSSL config() 


The OPENSSL config () call can be used to enable FIPS mode via the standard openss1.conf 
configuration file: 


OPENSSL config("XXXX conf") 


#ifdef OPENSSL FIPS 
if (FIPS mode()) 
( 
fprintf(stderr,"*** IN FIPS MODE ***\n"); 
) 
#endif 


Example 5.2b — Indirect Invocation of FIPS mode set() 
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# Default section 
XXXX_conf = XXXX options 


[ XXXX_options ] 
alg_section = algs 


[ algs ] 
fips_mode = yes 


Example 5.2c — Sample openssl.conf File 


The call to OPENSSL config("XXXX conf") will check the system default OpenSSL 
configuration file for a section XXXX_conf. If section XXXX conf is not found then the section 
defaults to openss1 conf. The resulting section is checked for an alg section specification 
naming a section that can contain an optional “fips_mode = yes” statement. 


Note that OPENSSL_config() has no return code. If a configuration error occurs it will write to 
STDERR and forcibly exit the application. Applications that want finer control can call the 
underlying functions such as CONF modules load file() directly. 


5.3 Generate Application Executable Object 


Note that applications interfacing with the FIPS Object Module are outside of the cryptographic 
boundary. 


When statically linking the application with the FIPS Object Module two steps are necessary: 


1. The HMAC-SHA-1 digest of the FIPS Object Module file must be calculated and verified 
against the installed digest to ensure the integrity of the FIPS Object Module. 


2. AHMAC-SHAI digest of the FIPS Object Module code and read-only data must be generated 
and embedded in the application executable object for use by the FIPS mode set () 
function at runtime initialization. 


Note the application that statically links the Module can be a shared library (DLL for Microsoft 
Windows). 


When the FIPS Object Module has been incorporated in a shared library then subsequent dynamic 
linking of an application to that shared library is done the usual way and these steps are irrelevant. 
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For static linking the embedding of the runtime digest can be accomplished in one of two ways: 
1. Two Step Linking with Interim Runtime Executable 


Earlier versions of the FIPS Object Module supported only this technique, where an initial link 

is performed to create an interim executable which is then executed in the target environment to 
calculate and display the digest value. A second link is performed to create the final executable 

with the embedded digest value. This two step process is typically performed by the fipslink.pl 

utility. 


This two step technique works well enough for native builds, where the build system and 
runtime target system are the same, but is awkward at best for cross-compilation due to the need 
to move the interim executable to the target system, execute it, and retrieve the calculated 
digest. 


This technique does have the advantage of working (at least in principle) for all platforms. 
2. In-place Editing of the Object Code 


In order to ease the task of cross-compiling the FIPS Object Module, a new technique was 
developed. Instead of determining the runtime digest value by actual execution on the target 
system, a utility is used to analyze the compiled object code on the build system and calculate 
the digest. This utility is platform (or object code format) sensitive. For ELF binaries it is called 
incore, for Microsoft Windows msincore, for OS X and 1OS incore macho. 


5.3.1 Linking under Unix/Linux 


The OpenSSL distribution contains a utility, fipsld, which both performs the check of the FIPS 
Object Module and generates the new HMAC-SHA- 1 digest for the application executable. The 
fipsld utility has been designed to act as a front end for the actual compilation and linking 
operations in order to ease the task of modifying an existing software project to incorporate the 
FIPS Object Module. It can be used to create either binary executables or shared libraries. 


The fipsld command requires that the CC and/or FIPSLD CC environment variables be set, 
with the latter taking precedence. These variables allow a typical Makefile to be used without 
modification by specifying a command of the form 


make CC-fipsld FIPSLD CC-2gcc 


where fipsld is invoked by make in lieu of the original compiler and linker (gee in this 
example), and in turn invokes that compiler where appropriate. Note that CC=fipsld can be 
passed to autoconf configure scripts as well. 
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This type of command line macro overloading will work for many smaller software projects. The 

makefile can also be modified to achieve the same macro substitutions. Depending on the form of 
the Makefile this substitution may be as simple as defining FIPSLD CC to reference the actual C 

compiler and redefining the CC macro to reference fipsld: 


FIPSLD CC = $(CC) 
CC = fipsld 


sappi saric $ (OBJS) 
$ (CC) $(SCFLAGS) -o $@ $(OBJS) $(LIBCRYPTO) 


Setting CC=fipsld is appropriate when the link rules rely on $ (CC) instead of 1d to produce the 
executable images, but in some cases it may be desirable or necessary to not redefine the $(CC) 
macro variable. A typical makefile rule referencing fipsld directly for the link step would look 
something like”: 


/usr/local/ssl/fips-2.0 
$ (OPENSSLDIR)/lib/fipscanister.o 


OPENSSLDIR 
FIPSMODULE 


RE lestions $ (OBJS) $ (FIPSMODULE) 
env FIPSLD CC-$ (CC) fipsld $(CFLAGS) -o $@ $(OBJS) \ 
$ (LIBS) $(LIBCRYPTO) 


Even though the £ips1d command name implies use as a replacement for the 1d command, it 
also invokes the C compiler between the two link stages, hence fipsld can also replace $ (CC) 
in rules producing .o object files, replacing both compilation and linking steps for the entire 
Makefile, i.e.: 


<application>.o: <application>.c 
$ (CC) S(CFLAGS) -c <application>.c 


«application»: $(OBJS) 
ld -o $@ $(OBJS) $(LIBCRYPTO) 


becomes 


“The use of env is actually redundant in a Makefile context, but is specified here to give a command line also valid 
for non-Bourne shells. 
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<application>: <application>.c 
env FIPSLD CC=$(CC) fipsld $(CFLAGS) -o $@ $@.c \ 
$ (LIBCRYPTO) 


Larger software projects are likely to prefer to modify only the Makefile rule(s) linking the 
application itself, leaving other Makefile rules intact. For these more complicated Makefiles the 
individual rules can be modified to substitute fipsld for just the relevant compilation linking 
steps. 


The fipsld command is designed to locate fipscanister.o automatically. It will verify that 
the HMAC-SHA-1 digest in file fipscanister.o.shal matches the digest generated from 
fipscanister.o, and will then create the file <application> containing the object code 
from fipscanister.o, and embedded within that the digest calculated from the object code 
and data in fipscanister.o. 


At runtime the FIPS mode set () function compares the embedded HMAC-SHA-1 digest with 
a digest generated from the text and data areas. This digest is the final link in the chain of validation 


from the original source to the application executable object file. 


5.3.2 Linking under Windows 


For a shared library application just linking with the DLL is sufficient. Linking an application with 
the static libraries involves a bit more work, and can be complicated by the fact that GUI based 
tools are often used for such linking. 


For the Windows® environment a perl script fipslink .pl is provided which performs a 
function similar to £àpsld for Unix®/Linux®. Several environment variables need to be set: 


FIPS LINK is the linker name, normally “link” 
FIPS CC is the C compiler name, normally “el” 
FIPS CC ARGS is a string of C compiler arguments for compiling fips premain.c 


PREMAIN DSO EXE should be set to the path to fips premain dso.exeifaDLLis 
being linked (can be omitted otherwise) 


PREMAIN SHA1 EXE is the full path to fips standalone shal.exe 


FIPS TARGET is the path of the target executable or DLL file 
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FIPSLIB Dis the path to the directory containing the installed FIPS module 


When these variables are specified fipslink.pl can be called in the same way as the standard 
linker. It will automatically check the hashes, link the target, generate the target in-core hash, and 
link a second time to embed the hash in the target file. 


The static library Makefile ms \nt . mak in the OpenSSL distribution gives an example of the 
usage of fipslink.pl. 


5.4 Application Implementation Recommendations 


This section describes additional steps not strictly required for FIPS 140-2 validation but 
recommended as good practice. 


Provide an Indication of FIPS Mode 


Security and risk assessment auditors will want to verify that an application utilizing cryptography 
is using FIPS 140-2 validated software in a FIPS compliant mode. Many such applications will 
superficially appear to function the same whether built with a non-FIPS OpenSSL, when built with 
the FIPS Object Module and running in non-FIPS mode, and when built with the FIPS Object 
Module and running in FIPS mode. 


As an aid to such reviews the application designer should provide a readily visible indication that 
the application has initialized the FIPS Object Module to FIPS mode, after a successful return from 
the FIPS mode set () API call. The indication can take the form of a tty or stdout 
message, a syslog entry, or an addition to a protocol greeting banner. For example a SSH server 
could print a protocol banner of the form: 


SSH-2.0-OpenSSH 3.7.1p2 FIPS 
to provide an easily referenced indication that the server was properly initialized to FIPS mode. 
Graceful Avoidance of Non-FIPS Algorithms 


Many applications allow end user and/or system administrator configurable specification of 
cryptographic algorithms. The OpenSSL API used with the FIPS Object Module in FIPS mode is 
designed to return error conditions when an attempt is made to use a non-FIPS algorithm via the 
OpenSSL API. These errors may result in unexpected failure of the application, including fatal 
assert errors for algorithm function calls lacking a testable return code. However, there is no 
guarantee that the OpenSSL API will always return an error condition in every possible permutation 
or sequence of API calls that might invoke code relating to non-FIPS algorithms. In any case, it is 
the responsibility of the application programmer to avoid the use of non-FIPS algorithms. 
Unexpected run-time errors can be avoided if the cipher suites or other algorithm selection options 
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are defaulted to FIPS approved algorithms, and if warning or error messages are generated for any 
end user selection of non-FIPS algorithms. 


5.5 Documentation and Record-keeping Recommendations 


The supplier or developer of a product based on the FIPS Object Module cannot claim that the 
product itself is FIPS 140-2 validated under certificate #1747. Instead a statement similar to the 
following is recommended: 


Product XXXX uses an embedded FIPS 140-2-validated cryptographic module (Certificate 
#1747) running on a YYYY platform per FIPS 140-2 Implementation Guidance section G.5 
guidelines. 


where XXXX is the product name (“Cryptomagical Enfabulator v3.1%”) and Y Y Y Y is the host 
operating system (“Solaris 10”). 


This statement asserts "user affirmation" of the validation per Section G.5 of the Implementation 
Guidance document. 


While not strictly required by the Security Policy or FIPS 140-2, a written record documenting 
compliance with the Security Policy would be a prudent precaution for any party generating and 
using or distributing an application that will be subject to FIPS 140-2 compliance requirements. 
This record should document the following: 


For the FIPS Object Module generation: 


1. Where the openssl-fips-2.0.tar.gz distribution file was obtained from, and how 
the HMAC SHA-1 digest of that file was verified per Appendix B of the Security Policy. 


2. The host platform on which the fipscanister.o, fipscanister.o.shal, 
fips premain.c,and fips premain.c.shal files were generated. This platform 
identification at a minimum should note the processor architecture (“x86”, *PA-RISC?,...), 
the operating system (“Solaris 10”, “Windows XP”,...), and the compiler (“gee 3.4.3”,...). 


3. An assertion that the fipscanister.o module was generated with the three commands 
./config [no-asm] 
make 
make install 
and specifically that no other build-time options were specified. 


4. Arecord of the HMAC SHA-1 digest of the fipscanister.o (the contents of the 
fipscanister.o.shal file). That digest identifies this specific FIPS Object Module; 
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if you immediately build another module it will have a different digest and is a different 
FIPS Object Module. 


5. An assertion that the contents of the distribution file were not manually modified in any 
way at any time during the build process. 


For the application in which the FIPS Object Module is embedded: 


1. A record of the HMAC SHA-1 digest of the fipscanister.o that was embedded in the 
application. 

2. An assertion that the application does not utilize any cryptographic implementations other 
that those provided by the FIPS Object Module or contained in the FIPS capable OpenSSL 
1.0.1 or 1.0.2 libraries (where non-FIPS algorithms are disabled in FIPS mode). 

3. A description of how the application clearly indicates when FIPS mode is enabled 
(assuming that FIPS mode is a runtime selectable option). Note that the application must 
call FIPS_mode_set (), whether that call is triggered by runtime options or not. 


5.6 When is a Separate FIPS 140-2 Validation Required? 


When a decision is made on whether a particular IT solution is FIPS 140-2 compliant, multiple 
factors need to be taken into account, including the FIPS Pub 140-2 standard, FIPS 140-2 Derived 
Test Requirements, CMVP FAQ and Implementation Guidance. The ultimate authority in this 
process belongs to the CMVP. The CMVP provides its current interpretations and guidelines as to 
the interpretation ofthe FIPS 140-2 standard and the conformance testing/validation process on its 


public web site http://csrc.nist.gov/groups/STM/cmvp/. 


In particular, the only official document known to us which discusses use of embedded 
cryptographic modules is the CMVP FAQ available at 
http://csrc.nist.gov/groups/STM/cmvp/documents/CMVPFAO.pdf. This FAQ (Frequently Asked 
Questions document) discusses incorporation of another vendor's cryptographic modules in a 
subsection of Section 2.2.1 entitled "Can I incorporate another vendor's validated cryptographic 
module". In particular, the following is specified: 


"Yes. A cryptographic module that has already been issued a FIPS 140-1 or FIPS 140-2 
validation certificate may be incorporated or embedded into another product. The new 
product may reference the FIPS 140-1 or FIPS 140-2 validated cryptographic module so 
long as the new product does not alter the original validated cryptographic module. A 
product which uses an embedded validated cryptographic module cannot claim itself to be 
validated; only that it utilizes an embedded validated cryptographic module. There is no 
assurance that a product is correctly utilizing an embedded validated cryptographic module 
- this is outside the scope of the FIPS 140-1 or FIPS 140-2 validation." 
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Note that the CMVP FAQ does specify that a FIPS 140-1/2 validated module may be incorporated 
into another product. It then specifies that making a decision on whether a product is correctly 
utilizing an embedded module is outside of the scope of the FIPS 140-1 or FIPS 140-2 validation. 


A subsection of Section 2.1 of the CMVP FAQ entitled "4 vendor is selling me a crypto solution - 
what should I ask?" states: 


"Verify with the vendor that the application or product that is being offered is either a 
validated cryptographic module itself (e.g. VPN, SmartCard, etc) or the application or 
product uses an embedded validated cryptographic module (toolkit, etc). Ask the vendor to 
supply a signed letter stating their application, product or module is a validated module or 
incorporates a validated module, the module provides all the cryptographic services in the 
solution, and reference the modules validation certificate number." 


It is specified that the module provides "all the cryptographic services in the solution". It is not 
specified that the module provides "all the security-relevant services in the solution". A typical IT 
product may provide a variety of services, both cryptographic and non-cryptographic. A network 
protocol such as SSH or TLS provides both cryptographic services such as encryption and network 
services such as transmission of data packets, packet fragmentation, etc. 


The FIPS 140-2 standard is focused on the cryptography. There are many generic security relevant 
functionalities such as anti-virus protection, firewalling, IPS/IDS and others which are not currently 
covered by the FIPS 140-2 standard. An anti-virus solution which uses a cryptographic module for 
its operations can satisfy requirements of the FIPS 140-2 by delegating its cryptographic functions 
to an embedded FIPS 140-2 validated module. Including the entire anti-virus solution in the FIPS 
140-2 validation would hardly improve the overall security since FIPS 140-2 does not currently 
have requirements in the field of anti-virus protection. In a similar fashion, the FIPS 140-2 
standard does not currently have requirements related to network vulnerabilities or denial of service 
attacks. 


Validated modules typically provide algorithm implementations only, no network functionality such 
as IPSec, SSH, TLS etc. This does not, for example, prevent Microsoft Windows from providing 
IPSec/IKE and TLS/SSL functionality. Therefore, for example, an OpenSSH based product 
properly using the OpenSSL FIPS Object Module would not differ from Microsoft using its 
Microsoft Kernel Mode Crypto Provider in Microsoft IPSec/IKE client which is shipped with every 
copy of Windows. Ifan application product delegates all cryptographic services to a validated 
module the entire product will be FIPS compliant. 


Since the CMVP does not have a formal program for validation of IT solutions with embedded 
FIPS 140-2 modules, the question is one of how the actual compliance/non-compliance is 
determined. In practice the compliance is determined by the federal agency/buyer selecting the 
solution. During the process the customer may contact the CMVP, testing labs or security experts 
for an opinion. In many cases, though, the buyers make such decisions independently. Here it 


Page 80 of 225 


User Guide - OpenSSL FIPS Object Module v2.0 


should be noted that FIPS 140-2 is only a baseline and each federal agency may establish its own 
requirements exceeding the requirements of FIPS 140-2. In the particular example of network 
protocols federal agencies generally do accept networking products (IPSec/TLS/SSH etc.) with 
embedded FIPS 140-2 validated cryptographic software modules or hardware cards as FIPS 140-2 
compliant. 


For those vendors desiring a “sanity check” of the compliance status of their OpenSSL FIPS Object 
Module based product, OpenSSL Validation Services (OVS) can perform a review and provide an 
opinion letter stating whether, based on information provided by the vendor, that product appears to 
OVS to satisfy the requirements ofthe OpenSSL FIPS Object Module Security Policy. This 
opinion letter can include a review by one or more CMVP test labs and/or a OpenSSL team 
member as appropriate. This opinion letter clearly states that only the CMVP can provide an 
authoritative ruling on FIPS 140-2 compliance. 


5.7 Common Issues and Misconceptions 


In the years since the first versions of the OpenSSL FIPS Object Module were validated we've seen 
new users of the FIPS module struggle with some of the same issues over and over again. Here we 
attempt to offer some possibly useful advice: 


5.7.1 Don't Fight It 


Rightly or wrongly, the Security Policy very clearly mandates specific fixed build commands. 
Normal and natural practice in other contexts is to use build-time configuration options to control 
aspects of the build process, but that is not an option here. Instead think about the end result you 
want to accomplish and whether that can be done by any other means. For instance, the default 
install location can't be specified by the usual --prefix- build-time configuration option. But, 
once created via the canonical commands you can copy the fipscanister.o and associated files 
somewhere else. So, one option is to create a new build system, build the FIPS module with 
whatever permissions necessary to write to the default --prefix location, copy from there to the 
desired destination, and then discard the build system. Yes, that's a silly waste of time from a 
technical software developer objective, but you wouldn't be using the FIPS module in the first place 
on purely technical considerations. 


5.7.2 Don't Overthink It 


We have seen quite a few software vendors make the mistake of trying to force the FIPS module 
build process into an in-house configuration management scheme. Our recommendation: don't do 
that. There is no point in trying to manage the individual source files of the FIPS module source 
tarball because the canonical build process mandates that you start with the original tarball, 
openssl-fips-2.0.tar.gz, Which has a fixed digest and cannot be modified. 


Likewise there is no point in constantly rebuilding the FIPS module from source. While legal, as 


long as the Security Policy build process is followed, there is no benefit to be gained from the 
generation of multiple binary modules. The source code can never change (the usual reason for a 
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structured build-from-source process), and per the recommendations in 85.5 each distinct binary 
FIPS module should be separately tracked. 


In lieu of trying to jam the mandated FIPS module build process into an existing elaborate in-house 
configuration management process, we recommend that the binary FIPS module be generated by 
hand one time only (per distinct platform) in a solemn documented ceremony, and that the resulting 
binary files be managed through the formal source/version/configuration control process. 


6. Technical Notes 


This section has technical details of primary interest to the FIPS module developers and more 
advanced users. The typical application developer will not need to reference this material. 


6.1 DRBGs 


With very rare exceptions the internal functioning of the DRBGs is irrelevant to the end user and 
application software. In FIPS mode DRBGs are transparently used by the OpenSSL RAND API 
and applications will automatically use them. 


Random numbers are critical for the proper operation of cryptographic software and hardware. The 
DRBG or Deterministic Random Bit Generator is intended as a higher quality replacement for the 
earlier PRNGs or Pseudo-Random Number Generators and is defined by SP 800-90A. 


6.1.1 Overview 


The way entropy is gathered and used for the DRBG is part of the FIPS capable OpenSSL so it can 
be modified outside the context of the FIPS 140-2 validation. The current version is in 
crypto/rand/rand lib.c. 


There is a "default DRBG" whose context is accessed using FIPS get default drbg(). 
This default DRBG is mapped to the RAND * () calls. By default, the FIPS Object Module will 
use the AES/CTR generator from SP800-90A, Section 10.2, DRBG Mechanisms Based on Block 
Ciphers. The default generator can be overridden by the calling application at runtime via the 
function RAND set fips drbg type(). The default is equivalent to CTR DRBG using 
AES with a 256 bit key and a derivation function. 


The actual default DRBG type can also be specified via a preprocessor macro when the "FIPS 
capable" OpenSSL is built: 


#ifndef OPENSSL DRBG DEFAULT TYPE 
#define OPENSSL DRBG DEFAULT TYPE NID aes 256 ctr 
#endif 
#ifndef OPENSSL DRBG DEFAULT FLAGS 
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define OPENSSL DRBG DEFAULT FLAGS DRBG FLAG CTR USE DF 
#endif 


This might be useful in environments where some DRBG type is mandated by local 
policy. For example, to use the HMAC DRBG with sha256 by default: 


./config -DOPENSSL DRBG DEFAULT TYPE-NID hmacWithSHA256 N 
-DOPENSSL DRBG DEFAULT FLAGS-0 (other options) 


The RAND add () function just seeds the OpenSSL non-standard PRNG and does not feed into 
the DRBG directly. However that function would be used if the DRBG was reseeded. The reason it 
does this is that the DRBG design does not permit the addition of "out of band" entropy; the 
addition of entropy needs to be combined with a generate operation (additional input) or a full 
reseed/reinstantiate (which would require the minimum entropy). Environments with a better 
source of entropy (e.g. fast hardware RNG) could do far better. 


The entropy callbacks are completely under application control so the calling application can 
override the ones provided by default. They can be set by supplying a callback function to 
FIPS_drbg_set_callbacks () after calling OPENSSL init (). This callback function is 
invoked whenever the DRBG requires additional entropy: 


size t (*get entropy) (DRBG CTX *ctx, unsigned char **pout, 
int entropy, size t min len, size t max len) 


A call to this function requests entropy bits of entropy in a buffer of between min len and 
max len size bytes inclusive. The values of these are mechanism specific and taken from 
SP800-90 tables. This callback should then return the amount of data in the buffer *pout and the 
length in the return value, or zero in case of being unable to retrieve sufficient entropy. 


Few applications provide external entropy callbacks; those that do define a (*get entropy)() 
callback which should return at least two full "blocks" of entropy where a "block" refers to the 
entropy source block length specified in FIPS drbg set callbacks(). 


This is because the FIPS 140-2 mandated continuous PRNG test has to be applied to the entropy 
source. It has to compare consecutive blocks (discarding the first) which means the entropy source 
needs to supply a multiple of the block size. 


Due to a bug in the callback code the "entropy" value passed is not correct, but as a workaround 
applications can determine an appropriate entropy value for themselves. The solution isn't obvious 
so a detailed discusson follows. 


FIPS drbg get strength() returns the strength of the DRBG context which is the number of bits of 


entropy needed to seed the DRBG without the continuous PRNG test. When an application adds its 
own entropy callbacks it has to tell the FIPS module what the block length of the entropy source is. 
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So arguably the entropy parameter with the continuous PRNG test is: 
FIPS drbg get strength(dctx) + block length * 8 


But, that calculation determines a maximum value and an entropy source could conceivably supply 
less. For instance, suppose we want 256 bits of entropy and the callback supplies it as high grade 
entropy uniformly in a 32 byte buffer (the absolute minimum) and has a 16 byte block length. An 
extra block is needed for the PRNG test so we should supply a 48 byte buffer (three blocks) and 
effectively 384 bits of entropy. 


Now suppose we have a low grade entropy source which provides just 1 bit of entropy per byte. 
Again assume it is uniform (e.g. we don't get 8 bits of entropy in byte 1 and nothing in the next 7). 
Again lets have a block size of 16 bytes. This time to get 256 bits of entropy the source must 
provides it in a 256 byte buffer. An extra block is required which makes 272 bytes but because we 
only have 1 bit of entropy per byte it just needs to supply 272 bits of entropy. 


Once this call completes successfully the DRBG is instantiated at the appropriate (maximum) 
security strength again taking values from SP800-90 and SP800-57. 


We request random data from the caller of sufficient entropy for the security level of the DRBG. 


When asymmetric algorithms are used (key generation, parameter generation and indeed signing 
for DSA/ECDSA) we check that the RNG has sufficient security strength (as dictated by the 
relevant standards) to perform the operation. Insufficient security strength is an error and the 
operation cannot be performed. 


There is a mechanism, "entropy draining", which causes the DRBG to automatically reseed after a 
certain number of uses. See SP800-90 for details of how this operates. The function 

FIPS drbg set reseed interval () can be used to modify the number of calls before 
auto reseeding. 


The function FIPS rand strength () returns the security strength of the default RNG (the 
one used for key generation et. al.). 


Individual operations (for example key generation) then check the security strength of the RNG and 
return a fatal error if there is insufficient security strength to complete the operation. The values 
used are from SP800-57. 


This check is performed by the following functions: 


fips check dsa prng() 
fips check rsa prng() 


Page 84 of 225 


User Guide - OpenSSL FIPS Object Module v2.0 


fips check ec prng() 


Currently there is no equivalent for DH. One could be added if required but it isn't clear how the 
strengths should be compared when PKCS#3 DH is used. 


There is no version for ECDH either but the only operation performed by that code (shared secret 
computation) does not make use of the RNG. 


By default the health checks are automatically performed every 22* generate operations; this count 
can be modified (up or down) by the calling application via the 

FIPS drbg set check interval() function. If a DRBG health check fails then 

the DRBG is placed in an error state that can be cleared by uninstantiating and reinstantiating the 
DRBG. 


For the CTR DRBG a flag allows the optional use of a derivation function. Note the DRBG is 
always instantiated at maximum security. 


6.1.2 The DRBG API 


All DRBG operations are performed through an opaque DRBG CTX structure which corresponds to 
an SP800-90 "instance". The function 


DRBG CTX *FIPS drbg new(int type, unsigned int flags); 


allocates and initializes a new DRBG_CTX structure for DRBG. The "type" and "flags" 
parameters determine the mechanism and primitives used and the security strength. Only the 
maximum security strength is supported for each type: i.e. it is not possible to instantiate the DRBG 
at lower than the maximum strength. 


In addition to type specific values the "flags" field can be set to DRBG FLAG TEST to enable 
"test mode". This mode disables periodic health checks and the continuous PRNG test. It is used for 
internal purposes and to support algorithm validation testing. This flag MUST NOT be set for a live 
instance. 


Before a valid DRBG_CTX is returned to the application an extensive health check is performed on 
a DRBG using the same mechanism and primitives. If the check fails an error is returned. 


If the type parameter is set to 0 an uninitialized DRBG structure is returned. This structure may be 
initialized by calling FIPS drbg init(). This function returns a valid DRBG CTX structure if 


it succeeds or NULL if it fails (for example a invalid type parameter). 


DRBG Characteristics 
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All four DRBGs defined by SP800-90 are implemented. The mechanisms, parameters and strength 
are summarized below: 


Hash DRBG 


The type parameters NID shal, NID_sha224, NID_sha256, NID sha384 and 
NID_sha512 select the hash DRBG and the corresponding hash primitive. The SHA1 Hash 
DRBG has a security strength of 128 bits, the SHA224 DRBG has a security strength of 192 bits 
and all others 256 bits. 


HMAC DRBG 


The type parameters NID hmacWithSHA1, NID_hmacWithSHA224, 
NID_hmacWithSHA256, NID_hmacWithSHA384 and NID_hmacWithSHA512 select the 


HMAC DRBG mechanism and associated hash primitive. Security strengths are the same as for 
the Hash DRBG. 


CTR DRBG 


The type parameters NID_aes_128_ctr, NID aes 192 ctrandNID aes 256 ctr 
select the CTR DRBG type using AES and the appropriate key length. TDES is not supported. 
The security strength matches the number of bits in the key. For this DRBG type the flag 

DRBG FLAG CTR USE DF is supported which enables the use of a derivation function. If this 
flag is not set a derivation function is not used. 


Dual EC DRBG 


The type parameter is of the form (curve << 16) | hash. The curve value 

NID X9 62 prime256v1 corresponds to the curve P-256, NID secp384r1 to P-384, and 
NID_secp521r1 to P-521. The hash value should be set to the same value as for the Hash 
DRBG. Thus (NID_secp384r1 << 16) | NID_sha224 corresponds to P-384 with hash 
SHA-224. As indicated in SP800-90 SHA1 can only be used with P-256 and SHA-224 cannot be 
used with P-521. P-256 has a security strength of 128 bits, P-384 192 bits and P-521 256 bits. 


Note: Due to widely reported serious vulnerabilities Dual EC DRBG has been removed from recent 
versions of the OpenSSL FIPS module. 


General Functions 


FIPS drbg init 


The function 
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int FIPS drbg init (DRBG CTX *dctx, int type, 
unsigned int flags); 


initializes a pre-existing DRBG_CTX. This is an efficiency measure to avoid the need to reallocate 
a new DRBG_CTX. This function returns 1 for success and zero or a negative value for failure. The 
return value -2 is used to indicate an invalid or unsupported type value. The type value cannot be 0. 
This function is otherwise identical to FIPS_drbg_new(). 


FIPS drbg free 
The function 
void FIPS drbg free(DRBG CTX *dctx); 


frees up a DRBG_CTX. After this call the DRBG CTX pointer is no longer valid. The underlying 
DRBG is first uninstantiated. 


FIPS drbg set callbacks 
The function 


int FIPS drbg set callbacks (DRBG CTX *dctx, 

size t (*get entropy) (DRBG CTX *ctx, unsigned 
char**pout, int entropy, size t min len, size t 
max len), 

void (*cleanup entropy) (DRBG CTX *ctx, unsigned char 
*out, size t olen), size t entropy blocklen, 
size t (*get nonce) (DRBG CTX *ctx, unsigned char 
**pout, int entropy, size t min len, size t 
max len), 

void (*cleanup nonce) (DRBG CTX *ctx, unsigned char *out, 

size t olen) 


); 


sets entropy and nonce callbacks for a DRBG_CTX. The DRBG CTX must be in an uninstantiated 
state to set the callbacks: i.e. the callbacks cannot be set on an instantiated DRBG. This function is 
typically called immediately following FIPS drbg new(). This function returns 1 for success 
and 0 if an error occurred: the only way an error can occur is if an attempt is made to set the 
callbacks of an instantiated DRBG. 


Whenever the DRBG requires entropy or a nonce the corresponding callbacks will be called. 
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The callbacks get entropy and get_nonce request "entropy" bits of entropy in a 
buffer of between min len and max_len bytes. The function should set *pout to the buffer 
containing the entropy and return the length in bytes of the buffer. 


If the source of entropy or nonce is unable to satisfy the request it MUST return zero. This will 
place the DRBG in an error condition due to the source failure. 


The callbacks cleanup_entropy and cleanup_nonce are called after the entropy or nonce 
buffers have been used and can be utilized to zeroize the buffers. The "out" and "olen" 
parameters contains the same value returned by the get function. 


The "entropy_blocklen" is used to specify the block length of the underlying entropy source. 
This is used for the continuous RNG test on the entropy source. 


FIPS drbg instantiate 
The function 


int FIPS drbg instantiate(DRBG CTX *dctx, 
const unsigned char *pers, size t perslen); 


instantiates a DRBG with the supplied personalization string pers. This function returns 1 for 
success and 0 for failure. 


If the personalization string is of an invalid length for the DRBG mechanism a non-fatal error is 
returned. 


Internally this function instantiates the DRBG. This will request entropy and a nonce using the 
supplied get entropy and get nonce callbacks. 


There are no security strength and prediction resistance arguments to this function. The DRBG is 
always instantiated at the maximum strength for its type and prediction resistance requests are 
always supported. 

This function returns 1 for success and 0 for failure. 

FIPS drbg reseed 


The function 


int FIPS drbg reseed(DRBG CTX *dctx, const unsigned char 
*adin, size t adinlen); 
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reseeds the DRBG using optional additional input "adin" of length "adinlen". 
If the additional input is of an invalid length for the DRBG mechanism a non-fatal error is returned. 
The get_entropy callback of the DRBG is called internally to request entropy. 
An extensive health check is performed on a DRBG of the same type before reseeding the DRBG. 
If this fails the DRBG is placed in an error condition and the caller must un-instantiate and re- 
instantiate the DRBG before attempting further calls. 
This function returns 1 for success and 0 for failure. 
FIPS drbg generate 
The function 
int FIPS drbg generate (DRBG CTX *dctx, unsigned char *out, 

size t outlen, int prediction resistance, 

const unsigned char *adin, size t adinlen); 
attempts to generate "out len" bytes of random data from the DRBG. Using optional additional 
input "adin" of length "adinlen". If the "predication resistance" parameter is non- 
zero a prediction resistance request will be made and internal reseeding of the DRBG and 


requesting entropy as required by SP800-90 is performed. 


If an attempt is made to request too much data for a single request or to supply additional input of 
an invalid length a non-fatal error is returned. 


If an internal request for entropy fails a fatal error occurs and the DRBG is placed in an error state. 
The caller must un-instantiate and re-instantiate the DRBG before attempting further calls. 


This function returns 1 for success and 0 for failure. 
FIPS drbg uninstantiate 
The function 
int FIPS drbg uninstantiate(DRBG CTX *dctx); 


uninstantiates a DRBG. This zeroizes any CSPs and returns the DRBG to an uninitialized state. 


FIPS drbg get app data, FIPS drbg set app data 
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The two functions 


void *FIPS drbg get app data(DRBG CTX *ctx); 
void FIPS drbg set app data(DRBG CTX *ctx, void *app data); 


get and retrieve an application defined pointer value. The meaning of this pointer is application 
defined and might for example contain a pointer to a handle representing the entropy source and the 
get entropy function could retrieve and make use of that pointer. 


FIPS drbg get blocklength 
The function 


size t FIPS drbg get blocklength(DRBG CTX *dctx); 


returns the block length of the DRBG. 


FIPS drbg get strength 
The function 


int FIPS drbg get strength(DRBG CTX *dctx); 


returns the security strength of the DRBG in bits. 
FIPS drbg set reseed interval 
The function 


void FIPS drbg set reseed interval(DRBG CTX *dctx, int 
interval); 


modifies the reseed interval value. The default is 2% blocks for the Dual EC DRBG and 2” 
generate operations for all other types. These values are lower than the maximums specified in 
SP800-90. 

RAND interface 


Cryptographic operations make use of the OpenSSL RAND PRNG API to request random data. A 
brief description of this is given below: 


int RAND bytes(unsigned char *buf,int num); 
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Generate num random bytes and write to buf. 
int RAND pseudo bytes (unsigned char *buf,int num); 


Generate num random bytes and write to buf. The random data does not have to be 
cryptographically strong. 


void RAND seed (const void *buf,int num); 


This function is used at various points to add data which may be useful for adding entropy to the 
PRNG. The buffer buf contains num bytes which can be used. 


void RAND add(const void *buf, int num, double entropy); 
This is similar to RAND seed () except that the data supplied has entropy "entropy". 
Default DRBG 


A special DRBG instance called the "default DRBG" is used to map the DRBG to the RAND 
interface. 


The function 


int FIPS drbg set rand callbacks (DRBG CTX *dctx, 

size t (*get adin) (DRBG CTX *ctx, unsigned char 
**pout), 

void (*cleanup adin) (DRBG CTX *ctx, unsigned char 
*out, size t olen), 

int (*rand seed cb) (DRBG CTX *ctx, const void *buf, 
int num), 

int (*rand add cb) (DRBG CTX *ctx, 
const void *buf, int num, double entropy) 


); 
defines various callbacks which control how RAND calls are mapped to DRBG calls. 
The get adin callback is used to retrieve optional additional data used whenever a request for 
random data is made using RAND bytes () or RAND pseudo bytes (). When this operation 


is complete cleanup adin is called to release the buffer. 


Note that RAND bytes () and RAND pseudo bytes () are equivalent operations for the 
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RAND mapping to the DRBG; they both call FIPS_drbg_generate (). The 
FIPS_drbg_generate () function can be called multiple times to satisfy a single request if 
the num value exceeds the amount of data that can be handled in a single DRBG request. 
The callbacks rand seed cb and rand add cb are called directly whenever RAND seed () 
or RAND add() are called. These are entirely application defined and could be used for example 
to add seed information to the entropy source. 
The function 

DRBG CTX *FIPS get default drbg (void); 


retrieves the default DRBG context. This can then be manipulated using the standard DRBG 
functions such as FIPS drbg init (). 


The function 
int FIPS rand strength (void); 
returns the security strength in bits of the default PRNG. 
DRBG Health Checks 
The function 
int FIPS drbg health check (DRBG CTX *dctx); 
initiates a health check on the DRBG. In addition health checks are also performed when a DRBG 
is first initiated (using FIPS drbg new () or FIPS drbg set ()) when a DRBG is reseeded 
explicitly using FIPS drbg reseed() and every health check interval calls to the 


generate function. This interval is by default 22 but can be modified by: 


void FIPS drbg set check interval (DRBG CTX *dctx, int 
interval); 


If any health check fails the DRBG is placed in an error state and no further operations can be 
performed on the DRBG instance until it has been reinitialized (uninstanstiated and initialized). 


Extended KAT of all DRBG Functions 


The function fips drbg single kat () performs an extended Known Answer Test (KAT) of 
all functions: 
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Instantiate DRBG with known data (entropy, nonce, personalization string). 

Perform generate operation without prediction resistance and check output matches 
expected value. 

Reseed with known data (entropy, additional input). 

Perform second generate operation without prediction resistance and check output matches 
expected value. 

Uninstantiate DRBG. 

Instantiate DRBG in test mode with known data (entropy, nonce, personalization string). 
Perform generate operation with prediction resistance and check output matches expected 
value set known entropy and additional input during this step. 

Perform second generate operation with prediction resistance and check output matches 
expected value. 

Uninstantiate DRBG. 


It is asserted that checking the output of the generate function in steps 2, 4, 7 and 8 ensures the 
previous operations completed successfully: i.e. set the DRBG internal state to the expected values. 


Extended Error DRBG Checking 


Extended error checking is performed by function fips_drbg_error_check (): 


Invalid parameters are fed into all DRBG functions in sequence as follows. Note that some tests 
(e.g. entropy source failure) leave the test DRBG in an error state and it has to be uninstantiated and 
instantiated again to clear the error condition. 


Do ON A 


Instantiate with invalid personalization string length. 

Instantiate DRBG with entropy source failure (returning zero entropy). 
Attempt to generate DRBG output from DRBG from step 2. 

Instantiate DRBG with too short an entropy string. 

Instantiate DRBG with too long an entropy string. 

Instantiate DRBG with too small a nonce (if nonce used in mechanism). 
Instantiate DRBG with too large nonce (if nonce used in mechanism). 
Instantiate DRBG with good data and generate output, check calls succeed. 
Attempt to generate too much output for a single request. 


. Attempt to generate with too large additional input. 

. Attempt to generate with prediction resistance and entropy source failure. 

. Set reseed counter to reseed interval, generate output and check reseed has been performed. 
. Test explicit reseed operation with too large additional input. 

. Test explicit reseed with entropy failure. 

. Test explicit reseed with too large entropy string. 

. Test explicit reseed with too small entropy string. 

. Uninstantiate DRBG: check internal state is zeroed. 
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Health Checking Performance 


The health checks are performed: 


1. When a DRBG is first initialized (1.e. before instantiation) a health check is performed on a test 
instantiation using the same mechanism and parameters. 


2. When a reseed operation is performed (other than for a prediction resistance request) a health 
check is performed on a test instantiation. This effectively performs a superset of the requirements 
for testing the reseed function i.e. it tests all functions including the reseed function. 


3. An internal counter determines the number of generate operations since the last health check. 
When this reaches a preset limit a health check is performed. This limit is set by default to 2% 
operations but it can be set to an alternative value by an application. 


4. When an application explicitly requests a health check with the call 
FIPS_drbg_health_check (). 


Abbreviated POST 


During a Power On Self Test (POST) an abbreviated KAT only is performed for one instance of 
each supported DRBG mechanism. This simply performs an instantiate and generate operation and 
checks that the output matches an expected value. 


6.2 Role Based Module Authentication 


Summary 


A role based authentication mechanism is implemented for the purpose of satisfying a U.S. Army 
procurement policy. The implementation is transparent to end users if the relevant default build 
options are left undisturbed, as should generally be the case. 


IMPORTANT NOTE: 
After the role based authentication mechanism described in this section was implemented, we 
learned that the original Army policy that motivated this implementation is no longer in 
effect, as confirmed in correspondence dated 2011-10-28 with CIO/G6 that yielded this 
statement: 


As a result of the Army's transition to the DoD Unified Capabilities 
Approved Products List (UC APL), both the Army's IA Approved Products List 
process and the May 21, 2009 "Letter to Industry were rescinded. (CIO/G-6 
memorandum dated May 2011). The above referenced document in its 
entirety, including paragraph 5a, no longer applies. 
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For more details please send inquires to: ArmyIAToolsconus.army.mil, 703- 
545-1677 or 703-545-1672. 


Background 


The FIPS module is a software library so the concept of authentication to the module doesn't make 
any sense. Fora Level 1 validation the CMVP does not require any module authentication, and 
there is no circumstance that we can envision for which such authentication would have any 
practical value for vendors or users. A little thought shows that authentication of a general purpose 
cryptographic library itself must necessarily be a pointless nuisance; consider for instance the 
vendor of a Linux distribution (Ubuntu, Red Hat, etc.) that elected to utilize authentication with the 
OpenSSL libraries. Such an OS distribution will typically default to dozens of individual 
applications utilizing those libraries, with dozens to hundreds more available as optional packages. 
Each and every one of those applications would have to contain the correct authentication 
credentials at all times. Application vendors would either have to be informed of those credentials, 
widely and publicly, or would be forced to ship their product with unauthenticated OpenSSL 
libraries (or libraries authenticated with different known credentials) to avoid the failures that 
would be caused by mismatched credentials. The result would be a mess that would provide more 
opportunities than obstacles to Evil Hackers. 


However, in 2009 the U.S. Army specified a set of acquisition requirements, in the form of a memo 
with a subject line of "Letter to Industry Concerning the Approval and Acquisition of Information 
Assurance (IA) Tools and Products in the United States Army" (see 
https://chess.army.mil/ascp/commerce/scp/downloads/standardspolicy files/letter to industry pdf). 
This mandate imposes additional requirements for FIPS 140-2 validated products, beyond those 
mandated by the CMVP. In particular, for Level 1 validations such as ours, it requires: 


5. Federal Information Processing Standards (FIPS): 


a. FIPS 140-2, Level I: This applies to cryptographic modules that are software only 
solutions (the software cannot be bundled or sold as a hardware-software solution) 
that are unable to achieve FIPS 140-2 Security Level 2. Overall FIPS 140-2 Level 1 
solutions must incorporate the following Cryptographic Modules Specifications to a 
higher security level: Roles, Services, and Authentication (Security Level 2) and 
Design Assurance (Security Level 3). 


The OpenSSL FIPS Object Module 2.0 validation cannot be at overall Level 2 because such a 
validation would necessarily tie the module to specific hardware. This Army policy was evidently 
directed at turnkey appliances (firewalls, mobile devices, etc.) and failed to consider the case of 
general purpose cryptographic libraries. 


The earlier v1.2.3 FIPS module (certificate #1051) predated the release of the Letter to Industry, 


and since then we've heard from quite a few software vendors who have experienced difficulty in 
selling to the Army because the v1.2.3 module didn't meet the 5a requirement. It turns out that 
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satisfying this requirement is easily handled at modest cost as a pure documentation effort in some 
contexts, such as when the test platforms have Common Criteria (CC) certified operating systems 
or the module itself actually implements authentication. 


However, the CMVP takes the not unreasonable position that validation at Roles, Services, and 
Authentication at Level 2 is not appropriate unless authentication actually takes place (note that in 
this context a non-CC certified operating system is considered to provide no authentication 
services). CC certified platforms are few and far between, and it makes no sense to implement 
authentication to a general purpose cryptographic library. 


So, that left us with a bit of a dilemma. The CMVP and Army policies are in direct conflict, and if 
we knew of any easy way to get two government bureaucracies to reconcile conflicting policies 
we'd tackle some easier challenges like brokering a permanent peace in the Middle East. 


After some deliberation and consultation with the test lab we concluded that the best resolution to 
this dilemma was to implement role-based authentication in a way that would satisfy both the 
CMVP and Army requirements without significantly impacting the end users. This goal was 
accomplished by requiring role based authentication for use of the module in FIPS mode, and then 
automatically and transparently performing that authentication in the "FIPS capable" OpenSSL. 
The end result is that the FIPS module plus "FIPS capable" OpenSSL combination -- by far the 
most common use of the FIPS module -- will behave for the calling application as if the role based 
authentication were not required. 


Note we already have a well established precedent for publishing secret credentials in the context of 
an open source based validation. The integrity test mandated by FIPS 140-2, which is accorded 
great significance, requires a HMAC-SHA 1 digest of the module contents (object code, roughly 
speaking). The HMAC digest is calculated from a secret HMAC key plus the data of interest, the 
purpose being to allow both authentication and confirmation of data integrity (only the entity 
knowing the secret key can generate the correct digest). For the very first validation we were faced 
with the challenge of where to store the secret HMAC key, as in open source code there is no 
suitable hiding place. After some deliberation the CMVP instructed us to just code the 
HMAC-SHA 1 digest as mandated and leave the secret key exposed in the source code. That same 
"secret" key has been in every validation since and is published in the corresponding Security 
Policy documents (Appendix B, itis 65 74 61 6f 6e 72 69 73 68 64 6c 63 75 70 
66 6d, equivalent to the ASCII string "etaonrishdlcupfm"). 


Implementation 


The FIPS mode set () function familiar to users of past versions of the OpenSSL FIPS Object 
Module is now defined in the "FIPS capable" OpenSSL, i.e. externally to the FIPS module. The 
corresponding function in the FIPS module that enables the FIPS mode of operation requires role 
based authentication in the form of a password argument. Note that FIPS 140-2 requires at least 
two roles; we defined two roles but both perform identically in all respects. 
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The build process for the FIPS module references three environment variables, with defaults if not 
explicitly set: 


FIPS_AUTH_KEY 
FIPS AUTH CRYPTO OFFICER 
FIPS AUTH CRYPTO USER 


These environment variables define the HMAC key and the HMACS of the passwords respectively. 
This are utilized during the standard: 


./config 
make 


The FIPS AUTH KEY defines the HMAC key which defaults to "etaonrishdlcupfm". 
The two passwords default to "Default FIPS Crypto Officer Password" and 
"Default FIPS Crypto User Password" respectively and appear in 
fips/fips utl.h. 


There are several ways to get the right format for the password HMACS, such as: 
echo -n «password» | openssl shal -hmac «hmac key» 


At runtime the calling application invokes FIPS module mode set(1, password). 
Internally this function generates the digest HMAC (FIPS AUTH KEY, password)and checks 
to see if that value matches either of FIPS AUTH CRYPTO OFFICER or 

FIPS AUTH CRYPTO USER. If the password does not match the error is treated the same as a 
fatal POST error. 


Validation Testing 


For use by the test lab in testing the role based authentication the following command line options 
are defined for the fips test suite utility, to specify the password value to be passed to 
FIPS module mode set(): 


none Null password 

bad Invalid password of sufficient length 

user The FIPS AUTH CRYPTO USER password 
officer The FIPS AUTH CRYPTO OFFICER password 


If none of those command line options are given the FIPS AUTH CRYPTO USER password is 
used. 
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Support in the "FIPS capable" OpenSSL 


A means is provided in the "FIPS capable" OpenSSL (which is just another application from the 
perspective of the FIPS module) to specify non-default passwords: 


Jeonfig <...options...> -DFIPS AUTH USER PASS="\"...password...\"" 


Please note this is not something likely to be of value in any real-world context, and a FIPS module 
built with non-default passwords is a likely source of problems. 


6.3 Self Tests 


As required by FISP 140-2 the FIPS module implements numerous self tests. Typically at least one 
self test is required for each cryptographic algorithm. 


Each test as it is performed can be examined through an optional callback: 
int (*fips post cb) (int op, int id, int subid, void *ex); 


Unless otherwise stated below the callback should always return 1. The "op" parameter indicates 
the operation being performed and can be one of: 


FIPS POST BEGIN: indicates that testing has begun but no tests have been performed 
yet. 


FIPS POST END: indicates all tests have been completed. The "id" parameter indicates 
the overall status of tests. It is 1 if all tests completed successfully and 0 if at least one test 
failed. 


For the remaining "op" values the "id", "subid" and "exstr" parameters indicate details of the 
specific test being performed. See complete descriptions of each test type for the meaning of these 
parameters. 


FIPS POST STARTED: indicates an individual test has started. 

FIPS POST SUCCESS: individual self test was successful. 

FIPS POST FAIL: individual self test failed. 

FIPS POST CORRUPT: a query as to whether self test failure mode should be set. 


If the callback returns O a failure is simulated for the referenced self test. The method used to 
simulate failure is documented against each test. 
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6.3.1 POST Tests 


The tests performed during POST are described below, along with the corresponding 
fips test suite option(s) to trigger the test (see Appendix B.5). 


6.3.1.1 Integrity Test 


The id field is set to FIPS_TEST_INTEGRITY. The remaining parameters are not used. This is 
indicated while incore integrity testing of the module itself is being performed. This operation 

performs an HMAC over sections of incore data and checks the value against an expected value set 
when the application is compiled [see 82.2 for a more comprehensive description of this operation]. 


If failure is being simulated an additional byte is HMACed in addition to the incore data to produce 
an HMAC value which will differ from the stored value. 


Triggered by the integrity option to fips_test_suite. 
6.3.1.2 DRBG Self Test 


The id field is set to FIPS_TEST_DRBG. The subid field is set to the NID of the DRBG being 
tested and the "exstr" field is of type (int *) which points to the DRBG flags being tested. 


An abbreviated KAT only test (not a full health check) is performed on each supported DRBG 
mechanism. Specifically, it is initialized in test mode, instantiated using known parameters, output 
is generated and the result compared with known good values. 


If failure is being simulated the "additional input" parameter to the generate operation is perturbed 


by setting it to a shorter length than the KAT value. This will result in data being generated which 
does not match the expected value. 


Currently the following DRBG mechanisms and primitives are tested as part of the POST: 
a) CTR DRBG using 256 bit AES and a derivation function. 
b) CTR DRBG using 256 bit AES without a derivation function. 
c) Hash DRBG using SHA256. 
d) HMAC DRBG using SHA256. 
e) Dual EC DRBG using P-256 and SHA-256. 
Triggered by the drbg option to fips test suite. 


6.3.1.3 X9.31 PRNG Self Test 
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The id field is set to FIPS_TEST_X931. The subid field is set to the key length of the PRNG 
in bytes. 


For the test the PRNG is set up in test mode. A known key, V (seed) and DT (date time vector) is 
supplied and the generated output (R) compared to an expected value. 


If failure is being simulated the known V value is corrupted by incrementing the first byte. This 
will result in generated data which does not match the expected value. 


Currently the POST tests the X9.31 PRNG using 128, 192 and 256 bit key lengths. 

Triggered by the rng option to fips test suite. 

6.3.1.4 Digest Test 

The id field is set to FIPS TEST DIGEST. The subid field is set to the digest NID being 
tested. The "ex" argument is not used. Currently only SHAI is tested in this way. Known data is 


digested and the resulting hash compared to a known good value. 


If failure is being simulated an extra byte is digested in addition to the known data which will result 
in a digest which does not match the expected value. 


Triggered by the shal option to fips test suite. 
6.3.1.5 HMAC Test 


The id field is set to FIPS_TEST_HMAC. The subid field is set to the associate digest NID 
being tested. The "ex" argument is not used. 


Known data is HMACed and the resulting hash compared to a known good value. 


If failure is being simulated an extra byte is HMACed in addition to the known data which will 
result in an HMAC which does not match the expected value. 


The digests SHA1, SHA224, SHA256, SHA384 and SHAS512 are tested in this way. 
Triggered by the hmac option to fips test suite. 
6.3.1.6 CMAC Test 


The id field is set to FIPS TEST CMAC. The subid field is set to the associated cipher NID 
being tested. The "ex" argument is not used. 
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Known data is CMACed and the resulting CMAC compared to a known good value. 


If failure is being simulated an extra byte is CMACed in addition to the known data which will 
result in an HMAC which does not match the expected value. 


The triple DES cipher and AES using 128, 192 and 256 bytes is tested for CMAC. 
Triggered by the emac option to fips test suite. 
6.3.1.7 Cipher Self Tests 


The id field is set to FIPS TEST CIPHER. The subid field is set to the NID of the cipher 
being tested, "ex" is not used. 


A known key, IV and plaintext is encrypted and the output ciphertext compared to a known good 
value. 


The ciphertext is then decrypted using the same key and IV and the result compared to the original 
plaintext. 


If a failure is being simulated the ciphertext is corrupted (first byte XORed with 0x1) before the 
decryption test. 


AES in ECB mode with a 128 bit key and triple DES in ECB mode are tested. 
Triggered by the aes, des options to fips_test_suite. 
6.3.1.8 GCM Self Test 


The id is field is set to FIPS_TEST_GCM. The subid field is set to the NID of the cipher being 
tested, "ex" is not used. 


A known key, IV, AAD and plaintext is encrypted and the output ciphertext and tag compared to 
known good values. 


The ciphertext and take is then decrypted using the same key, IV, AAD and expected tag and the 
result compared to the original plaintext. 


If a failure is being simulated the tag is corrupted (first byte XORed with 0x1) before the 
decryption test. 


AES in GCM mode with a 256 key is tested. 
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Triggered by the aes—gem option to fips_test_suite. 
6.3.1.9 CCM Self Test 


The id field is set to FIPS_TEST_CCM. The subid field is set to the NID of the cipher being 
tested, "ex" is not used. The test is otherwise identical to the CCM test. 


AES in CCM mode with a 192 bit key is tested. 

Triggered by the aes—ccm option to fips test suite. 

6.3.1.10 XTS Self Test 

The id field is set to FIPS TEST XTS. The test is otherwise identical to the cipher tests. 
AES in XTS mode with a 128 and a 256 bit key is tested. 

Triggered by the aes-xts option to fips test suite. 

6.3.1.11 Signature Algorithm Tests 

The id field is set to FIPS TEST SIGNATURE. The subid field is set to the NID of the 
associated digest. The "ex" field is set to the EVP_PKEY structure of the key being used in the 
KAT. By examining exstr the type of key being tested can be determined. 


A signature is calculated using a known private key and data to be signed. 


For deterministic signature algorithms (i.e. RSA in some padding modes) the signature is compared 
to a known good value. 


The signature is then verified using the same data used to create the signature. 
If failure is being simulated an extra byte is digested in addition to the known data for signature 
creation only. This will result in a signature which does not match the expected value (if this test is 
being performed) or the verification will fail. 
The following algorithms are tested: 

a) RSA using PSS padding and SHA256 with a 2048 bit key. 

b) ECDSA using P-224 and SHAS512. 


c) ECDSA using K-233 and SHA512 if binary fields are supported. 
d) DSA using SHA384 and a 2048 bit key. 


Page 102 of 225 


User Guide - OpenSSL FIPS Object Module v2.0 


Triggered by the dsa, ecdsa, rsaoptionto fips test suite. 
6.3.12 ECDH Self Tests 


The id field is set to FIPS TEST ECDH. The subid field is set to the NID of the curve used. The 
"ex" field is not used. 


Known private and public ECDH keys are used to compute a shared secret (Z) value. This is 
compared to a known good value. 


If failure is being simulated the computed shared secret is corrupted after generation. This will 
result in a mismatch with the expected value. 


Triggered by the ecdh option to fips test suite. 


6.3.2 Conditional self tests. 


6.3.2.1 Pairwise consistency Test 

When an asymmetric signature key is generated a signature test identical to the POST signature 
tests is performed on the generated key. The only difference is the id field is set to 

FIPS TEST PAIRWISE. 

In the case of RSA keys a consistency test is also performed using an RSA PKCS#1 padding 
encryption and decryption operation: this operation is not registered with the callback. Specifically: 
known data is encrypted, the ciphertext checked it does not match the plaintext and then decrypted. 
The decrypted value is checked against the original plaintext. 


For RSA keys the SHA256 digest is used and three tests performed PKCS#1, X931 and PSS 
padding. 


For DSA and ECDSA keys one test using SHA256 is performed. 
Triggered by the dsakeygen and rsakeygen options to fips test suite. 
6.3.2.2 Continuous PRNG Test 


When not in test mode (i.e. an operational "live" PRNG) the output of the PRNG is put through the 
continuous PRNG test for FIPS 140-2. 


The callback is not used for this operation. 
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If the function FIPS x931 stick() is called then the X9.31 PRNG output is copied to the 
stored last block to ensure the test will fail on the next generate operation. 


If the function FIPS drbg stick () is called then the X9.31 PRNG output is copied to the 
stored last block to ensure the test will fail on the next generate operation. 


The continuous PRNG test for the PRNG itself is triggered by the drbgstick and rngstick 
options to fips test suite. The continuous PRNG test for the entropy source is triggered by 
the drbgentstick option to fips test suite. 


6.4 ECDH 
The CAVP defines a test for ECDH in the form of "ECC CDH Primitive" tests: 


http://csrc.nist.gov/groups/STM/cavp/#09 


When this ECDH testing was introduced for FIPS 140-2 we initially assumed that with the growing 
use of ECDH in TLS the intent was to ensure that usage was covered by an approved algorithm. 


That turns out not to be the case. The algorithm now available for testing is "cofactor ECDH" 
(formally known as ECC CDH) which is NOT the same as regular ECDH (formally known as as 
the ECKAS-DHI scheme) used with TLS -- it is a variant of ECDH that is not the same as that 
commonly used in actual applications. 


The differences between the two algorithms are small but enough to make the two incompatible in 
subtle ways. 


For regular ECDH the shared secret Z is the x component of the value dQ where d is one sides 
private key (an integer) and Q the other sides public key (an elliptic curve point). 


For cofactor ECDH the shared secret Z is the x component of the value hdQ where the new value h 
is something called the cofactor (another integer) which is a property of the curve. For most 
primes? curvesh = 1 whereas for many binary curves h + 1. So for many prime curves (but 
not all) the two algorithms yield the same result. For binary curves they do not. 


Note that the addition of a few lines to the ECDH algorithm implementation changes it to cofactor 
ECDH at which point it passes the CAVP ECC CDH Primitive test. However, if we change our 
ECDH implementation to unconditionally use cofactor ECDH then it will not be interoperable with 
TLS using binary curves. 


“The standard tested prime curves all use h = 1 excepting one non standard prime curve with h != 1; that is a 128 bit 
curve and so forbidden in approved mode. Effectively this means that for an implementation only checking prime 
curves (as many do) then the discrepancy would never be apparent. FIPS 140-2 does allow non-standard curves so two 
"tested" algorithms could yield the different results. 
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Even though the use of cofactor ECDH is rare at present, there could conceivably be a need at some 
point. In order to accommodate that possibility while preserving compatibility with existing 
applications we added a flag to the EC_ KEY structure to enable cofactor ECDH for use with the 
FIPS 140-2 algorithm tests. This flag is set with the EC KEY set flags() function: 


EC KEY set flags(key, EC FLAG COFACTOR ECDH); 
If this flag it is not explicitly set then the ECKAS-DHI (TLS compatible) scheme is used. 


6.5 ECC and the NSA Sublicense 


Why are there two versions of the OpenSSL FIPS Object Module 2.0? 


At least some implementations of Elliptic Curve Cryptography (ECC) are perceived to be 
encumbered in the United States by a complex set of patents. Concern about the possible risks of 
patent infringement have been a significant disincentive to more widespread use of ECC. 


In order to counter such concerns for the ECC necessary to implement the Suite B algorithms, the 
NSA established a process for sub-licensing the patents for that subset of ECC (see 


http://www.nsa.gov/ia/programs/suiteb cryptography/index.shtml). OVS has obtained such a 
sublicense (http://openssl.com/testing/docs/NSA-PLA. pdf). 


However, that sublicense only covers the specific patents presumed relevant to the prime curve 
ECC used for Suite B. It does not cover other possible types of ECC such as binary curves which 
are implemented in OpenSSL. 


Judging the risks of a patent infringement lawsuit is difficult, and not only because the patents 
themselves are usually incomprehensible to the software developer. The mere threat of a patent 
lawsuit can be crippling to even a medium sized enterprise, regardless of the legitimacy of the 
accusation of infringement. 


It is the belief of the OpenSSL team that the implementation of ECC in OpenSSL, both primary and 
binary curve, does not infringe any patents”. However, we aren't lawyers and patent law is 
notoriously perverse. Some potential users are still concerned about the risk of patent litigation, 
understandably so given the extent to which such litigation has been used as an offensive 
commercial tactic in recent years. For the OpenSSL software such users can use build-time options 
to omit specific algorithms of concern from the resulting binary code. 


However, the restrictions of FIPS 140-2 prevent the use of such build-time options or modification 
of the source code. One of the validation sponsors was concerned about patent risks and so a 


“Also note that the bulk of the binary curve ECC implementation to the OpenSSL project was contributed by a 
corporation, the former Sun Microsystems, with the legal resources to analyze such risks. 
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separate "patent troll" source distribution of the OpenSSL FIPS Object Module 2.0 was created 
which entirely omits the binary curve ECC. That distribution, openss1-fips-ecp-2.0.tar.gz, IS 
functionally identical to the full distribution except for the omission of those algorithms, and all 
discussion of the full distribution elsewhere in this document applies. 


Note that when using the "ecp" distributions the corresponding "FIPS capable" OpenSSL must be 
built with the no-ec2m option. 


6.6 The "Secure Installation" Issue 


This latest of the OpenSSL FIPS Object Module ("FIPS module") FIPS 140-2 validations saw the 
introduction of a new requirement by the CMVP: 


The distribution tar file, shall be verified using an independently acquired FIPS 140-2 
validated cryptographic module... 


We're told that this distribution tar file verification requirement comes directly from the assertions 
AS10.03 and AS14.02 of the Derived Test Requirements document: 


AS10.03: (Levels 1, 2, 3, and 4) Documentation shall specify the procedures for secure 
installation, initialization, and startup of the cryptographic module. 


4814.02: (Levels 1, 2, 3, and 4) The cryptographic module security policy shall consist 
of: a specification of the security rules, under which the cryptographic module shall 
operate, including the security rules derived from the requirements of the standard and 
the additional security rules imposed by the vendor. 


Subsequent discussions mediated by the test lab elaborated this "secure installation" requirement to 
mean that one of the following conditions must be true: 


1) The distribution file is obtained via a "trusted path", which is one of: 


a) Transfer via physical media (e.g. CD-ROM disk) sent by postal or delivery service 
(USPS, UPS, FedEx); 


b) Electronic transfer using cryptography (e.g. SSH, HTTPS, IPsec) implemented by FIPS 
140-2 validated products. That requirement was further elaborated to state that those 
products must themselves be a result of "secure installation". 


2) The distribution file is verified (HMAC-SHA-1 digest checked) using a pre-existing FIPS 
140-2 validated product that is itself the result of a "secure installation". 


Note the recursive nature of the "secure installation" requirement represents a non-trivial challenge; 
in order to transfer or verify a new validated product an existing securely installed validated 
product must already be present. We're still struggling to understand the scope and implications of 
this requirement. The FIPS 140-2 scripture (The FIPS 140-2 standard [Reference 1], the DTR 
[Reference 4], and the IG [Reference 3] documents) doesn't shed a lot of light -- the term "trusted 
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path" for instance is only referenced in the context of Level 3 validations. Note those "secure 
installation" and "trusted path" requirements as explained to us say that validated software cannot 
be distributed by traditional methods, which leads to some interesting questions about the use of 
other validated modules (puzzlement over why all other modules aren't similarly impacted is a large 
part of our confusion). Those questions aside, prospective users of this FIPS module need to 
determine at least one known valid way to satisfy the requirement for this specific validation -- a 
way not at risk of being ruled invalid by the CMVP after software has been shipped or deployed. 


So far the CMVP has declined to answer specific questions about options for satisfying this 
requirement; they quote the formal documentation (as noted above) and refer us to the test labs. We 
have actively discussed this issue with several accredited test labs and selected members of the 
FIPS validation community. Unfortunately the test labs are not in close agreement. So far we have 
collected a lot of opinions but not much certainty. If you have experience or insights directly 
relevant to this issue we'd love to hear from you”. 


Very Important Note: 

The conclusions presented here are still tentative as they have neither been confirmed nor 
refuted by the CMVP; they simply represent our best understanding of the situation at this 
point in time. These conclusions could change dramatically based on relevant feedback from 
the CMVP, or more slowly in response to an accumulated consensus of opinion from the test 
labs and FIPS 140-2 community of interest. 


6.6.1 What Won't Work 


This new requirement doesn't sound so bad until you try to pin down exactly what steps need to be 
taken to satisfy it. We're still working on figuring this out, but we can eliminate some options that 
have been considered but which apparently are not allowed: 


* No delegation: one entity (OVS for instance) can't perform the verification of the source 
tarball and then post that verified tarball on a website for download by everyone else unless 
the download qualifies as a "trusted path", which in practice will mean the user performing 
the download will need to obtain and install FIPS 140-2 validated client software (also 
through a trusted path ... which is a circular problem for many users). 


* The new module itself (what is built from the source distribution) cannot be used to perform 
the verification of the source distribution 1t was built from. 


+ Earlier FIPS modules (such as the 1.2.3 FIPS module, validation certificate number #1051) 
apparently cannot be used to perform the verification. Apparently the new tarball 
verification requirement will be retroactively applied to the older OpenSSL FIPS Object 
Module validations. We do not know 1f that will mean that all deployed instances of these 
older modules will be declared invalid (that would have a huge impact), but the consensus 
of our discussions is that the older modules can't be leveraged to verify the new module. 


- Use of an earlier binary module validation (certificate #1111) was suggested by the CMVP. 
There are two problems with that suggestion; first, that particular validation took so long 


“http://openssl.com/contact.html 
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(with a 13 month wait for CMVP action) that it had no economic value by the time it was 
finally completed, and as a result it was abandoned and we no longer have the 
corresponding binary module; and second, per our understanding that binary module would 
need to be executed on some very obsolete platforms (OpenSuSE 10.2, no longer 
downloadable from the maintainer, or Microsoft Windows XP SP2, no longer sold by the 
vendor). Also in many environments (such as DoD) use of such unsupported operating 
systems is forbidden by security policy. 


One of our first thoughts was to create (by some means) an executable binary utility 
program to perform the verification, that could be run on one or more common platforms 
(e.g. Linux, Windows), and that we could provide publicly for everyone. However, 1t seems 
we can't just post that utility for download on a typical web site as the downloaded file 
would not have been obtained through a "trusted path". Our understanding is that a trusted 
path over a network would require formally FIPS 140-2 validated software at both the client 
and server which fails to address the issue of how to get validated cryptography in the first 
place. 


Another clever idea that was suggested was for us to provide a utility based on a known 
common commercial validated cryptographic implementation, such as CryptoAPI in 
Microsoft Windows. The utility could be freely downloaded because it would not contain 
the actual cryptography. However, many prospective users will have obtained that validated 
cryptography (the Microsoft Windows OS itself) by non-trusted means (the MSDN 
download of ISO images does not use FIPS validated cryptography, nor does the usual 
Internet based update process). Likewise an NSS based utility for Red Hat Enterprise Linux 
would have the same problem (non-trusted installation and update). Even if the initial OS 
installation was done with a trusted path, the subsequent routine updates are not?'; so one 
would have to install the OS using a vendor supplied CD/DVD and then not subsequently 
update it over the Internet. 


Note this last point is downright mind-boggling: it amounts to an assertion that essentially 
all installations of validated software modules are illegitimate. 


Many other options have been considered as well, without a clear consensus from those in the test 
labs and the community of interest who we have consulted. 


6.6.2 What Might Work 


The options that we are fairly confident will satisfy the new requirement are: 


Use of a commercial proprietary product using FIPS 140-2 validated cryptography, obtained 
via a trusted path (e.g. snail-mailed CD or DVD), to display the HMAC-SHA-1 digest of the 
source tarball. That product should be capable of performing the equivalent of: 


openssl shal -hmac etaonrishdlcupfm openssl-fips-2.0.tar.gz 


"We were able to connect to both Microsoft and Red Hat distribution servers with non-allowed cryptographic 
algorithms (e.g. RC4); hence we can deduce that those servers are not utilizing FIPS 140-2 validated cryptography. 
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As noted above, for reasons we don't understand the earlier OpenSSL FIPS Object Module 
validations (e.g. #1051) are apparently not eligible for this role. At this point we are not 
aware of any specific commercial products that perform this operation on a file, nor how 
much they cost or how to purchase them. However, such products must exist. If you know 
of or find a suitable product please let us know” the details. 


* Use of a source code distribution that can be obtained from OVS on physical media (a CD- 
ROM disk) via snail-mail (USPS). 


Note this option is specifically documented? as acceptable in the Security Policy itself -- a 
huge comfort factor for those concerned about the lack of clear guidance in this area. Also 
note that some experienced and respected commentators in the FIPS 140-2 community of 
interest that we consulted felt strongly that physical media should not constitute a trusted 
path. However, a direct statement as placed in the Security Policy and approved by the 
CMVP trumps any such concerns. 


Until and if the postage costs get out of hand we will send those CDs on request at no cost. 
Please send your request including a full postal address to verifycd@openssl.com. Note that 
the files you will receive on these CDs will be identical in every respect (except for FIPS 
140-2 compliance) with the files you can download from the openssl.org web site, so we ask 
that you only request this CD if you plan to use it for generation of FIPS 140-2 validated 
cryptography in a context that requires such compliance. The downloaded files are bit-for- 
bit identical and for any other purposes will generate exactly the same results. 


6.6.3 Still Confused? 


Welcome to the club. As we learn more about specific options that will and won't satisfy the 
requirement we will post that information on the OVS web site and in updates to this document. In 
the meantime the only definitive answers will have to come from the CMVP itself, either directly or 
indirectly. The best point of contact is the Director of NIST CMVP™. If you choose to contact the 
CMVP then please: 


- Keep all inquiries polite and respectful. 


- Remember that the CMVP have a very different perspective on computers and software than 
the average information technology practitioner. They do not have a software development 
background. 


* Note that they are not the enemy; if it was their intent to consciously block or sabotage the 
OpenSSL FIPS Object Module validations they could have done so easily long ago using a 
wide range of bureaucratic tactics. 


“http://openssl.com/contact.html 

“The discussions leading to this statement in the Security Policy were responsible for several weeks of delay in 
obtaining the validation. We felt the issue of having one specific affirmatively approved process for satisfying this new 
requirement was so critical as to warrant any necessary delay; placement of that statement in the Securitiy Policy itself 
was essentially our only opportunity to obtain a definitive response on the topic from the CMVP. 
“http://csrc.nist.gov/groups/STM/cmvp/contacts.html 
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Note that if you disagree with what you are told by the Director of NIST CMVP you have 
no recourse to appeal to any higher authority; his word is definitive and final (technically 
the CMVP is a joint U.S.-Canadian program with the CSE» as the Canadian equivalent of 
NIST, but for U.S. users at least the NIST CMVP opinion is what matters. Canadian users 
may want to consult the CSE). 


If you learn anything of interest please share it with us* and/or one of the OpenSSL mailing 
lists”. 


6.7 GMAC 


The FIPS module was originally tested with, and awarded an algorithm validation for, AES GCM 
including GMAC. The CAVP subsequently revised the algorithm and retroactively designated a 
number of validations, including ours, as "GMAC not supported". 


6.7.1 CAVP Action 


We first heard of this in an E-mail forwarded by our test lab, at which time the CAVP and CMVP 
web site listings had already been updated to show "GMAC not supported" for multiple validations. 


The CAVP noted that our GCM implementation gave an incorrect answer when a zero length 
plaintext is given with an AAD input length that is not a multiple of 128 bits. The original GMAC 
test only checked input lengths that were a multiple of 128 bits. 


Note this preemptive action appears to be a little unusual, typically the CAVP/CMPV will contact a 
vendor to discuss problems before taking unilateral action. 


6.7.2 Options for Addressing 


The fix is a trivial one line code change, http://cvs.openssl.org/chngview?cn-22745, which has 
been applied to the regular OpenSSL releases. However, changes to FIPS 140-2 validated software, 
no matter how trivial, are not easily effected. In this case the CAVP insisted on retesting of all of 
the 50 some previously tested platforms. 


Retesting was not economically feasible due to multiple factors: 


Many test devices had already been returned to the platform sponsors. Some of those were 
one-off prototype or evaluation units and arranging with the sponsors to re-ship that 
equipment to the OVS test lab would have taken a substantial amount of time and effort. 
Even shipping costs themselves were non-trivial, as OVS pays return shipping for customer 


*http://www.cse-cst.gc.ca/index-eng.html 


*http://openssl.com:/contact.html 
http://openssl.org/support/community.html 
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supplied equipment. Those costs alone were several thousand dollars for the initial 2.0 FIPS 
module testing. 


- Many man-weeks of effort would have been required to repeat the process of installing and 
configuring each test device and then running the software build and execution process. 


- We would have to pay the test lab for the testing, a very substantial cost. Even with 
negotiations to take into account the fact that the testing process was already fully 
documented and tested for each device, that cost would probably have been at least 
US$50,000. 


All told we estimated the cost of retesting every platform would exceed US$70,000 even with OVS 
personnel working for minimum wage. 


Fortunately the practical impact of removing GMAC from the 2.0 module validation appears to be 
minimal, as discussed in the following section. 


This incident does illustrate the risk of unpredictable and unilateral CAVP/CMVP action. Passing 
all the formal testing and receiving a validation award is no guarantee that the validation will not 
disappear overnight”. That perceived risk is a large part of the appeal of the "private label" 
validations for risk-adverse clients. 


6.7.3 Practical Impact 


The AES-GCM algorithm is an authenticated encryption algorithm. It is in some ways equivalent to 
the separate HMAC and encryption algorithms used in some ciphersuites. It is an attractive choice 
because it does everything all in one go and thus is is considerably faster than the separate 
encryption MAC operation. The first widespread use of GCM is in TLS 1.2 in new ciphersuites. 


AES-GCM as its input can take (among other things) some additional authenticated data (AAD) 
and plaintext (in encrypt mode). Its output is ciphertext and a MAC. 


The AAD is used as some additional data to throw into the MAC calculation but it does not appear 
in the output. The ciphertext is the encrypted plaintext. 


If there is any plaintext/ciphertext at all then the operation is called GCM, with or without AAD. 


If there is no ciphertext/plaintext and only AAD then the operation is called GMAC. So GMAC is a 
special case of GCM. 


That has happened before, for instance the earlier OpenSSL FIPS Object Module validation #733 which was 
effectively revoked by the CMVP. See http://veridicalsystems.com/blog/index.html?p=55.html for a discussion of that 
incident. 
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The bug in the FIPS module GCM implementation is triggered when GMAC is used, i.e. there is no 
ciphertext/plaintext and only AAD. Also the bug is not manifested unless the AAD is not a multiple 
of 16 bytes. 


So if the AAD is a multiple of 16 bytes and/or there is any ciphertext/plaintext then the FIPS 
module implementation works just fine. 


During normal operation of the TLS protocol GMAC is not used because there is always some data 
to encrypt or decrypt. The degenerate case of a zero length fragment we think could trigger this but 
OpenSSL never produces such a thing and there is no reason for a non-OpenSSL TLS stack to do so 
either. Further review may be needed to determine if a TLS 1.2 zero length fragment case is even 
theoretically possible. 


So to summarize: under any normal use cases the OpenSSL TLS implementation works in FIPS 
mode just fine without GMAC. 


6.8 DH 


The version of DH used by TLS is a variant on PKCS#3 and not the X9.42 specification, and hence 
is not compliant with SP800-56A. For example, the requirement: 


Each private key shall be unpredictable and shall be generated in the range [ 1, 
q-1] using an Approved random bit generator. 


"aen 


For TLS clients that requirement cannot be satisfied as stated because the parameter "q" is not sent 


Min 


from server to client, only the parameter "p". Clients generate a private key in the range [1, p-1] 
instead. 


6.9 DSA 
The DSA private key value is calculated as follows: 


The function fips check dsa prng()checks parameters and that the PRNG strength is 
consistent with them when a private key is generated. The function fips_ffc_strength () 
which takes the values directly from SP800-131A is used as well. 


6.10 CCM 
CCM is "Counter with Cipher Block Chaining-Message Authentication Code" per SP800-38C. 


The openssl ciphers command does not show anything for CCM as that command only lists 
the cipher suites for SSL/TLS. For OpenSSL 1.0.2 and earlier CCM mode is not supported for TLS 
in OpenSSL: such support was not requested by any validation sponsors and it wasn't even a 
finalised standard at the time. Newer versions of OpenSSL do support CCM but the cipher string is 
AESCCM because CCM can apply to other ciphers. 
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Appendix A OpenSSL Distribution Signing Keys 


In order to be considered FIPS 140-2 validated the FIPS Object Module must be derived from an 
OpenSSL distribution signed by one of these authorized keys, as shown by the value in the 
Fingerprint row. These keys are subject to change and the list at https://openssl.org/about/ will 
generally be more current. 


The procedure for verifying that a source distribution was signed by one of these keys is described 
in detail in $4.1.2. 


Note the fingerprint formats are slightly different for the two different types of keys (RSA and 
DSA). 


OpenSSL Core Team PGP Keys 
Key Id Team member 


0E604491 | Matt Caswell matt@openssl.org 
fingerprint: 8657 ABB2 60F0 56B1 E519 0839 D9C4 D26D OE60 4491 


49A563D9 | Mark J. Cox mark@openssl.org 
fingerprint: 7B 79 19 FA 71 6B 87 25 OE 77 21 E5 52 D9 83 BF 


Viktor Dukhovni viktor@openssl.org 


FA40E9E2 | Dr. Stephen Henson steve@openssl.org 
fingerprint: 6260 5AA4 334A F9F0 DDE5 D349 D357 7507 FA40 E9E2 


41FBF7DD | Tim Hudson tjh@openssl.org 
fingerprint: 60A6 0B21 E22D CEDD C50C 0773 06CC 497B OEEA BFE4 


BDD52F1C | Lutz Jänicke jaenicke@openssl.org 
fingerprint: 0A77 335A ADE7 4E6B B36C ADBA DFAB 592A BDD5 2F1C 


Emilia Kasper emilia@openssl.org C 


2118CF83 | Ben Laurie ben@openssl.org 
fingerprint: 7656 55DE 62E3 96FF 2587 EB6C 4F6D E156 2118 CF83 
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6D1892F5 | Steve Marquess marquess@openssl.org 

fingerprint: FEAB 1FB2 6537 1742 9BOB 894F 4317 11F7 6D18 92F5 
7DF9EE8C | Richard Levitte levitte@openssl.org S 

fingerprint: 7953 AC1F BC3D C8B3 B292 393E D5E9 E43F 7DF9 EE8C 
4A397EA2 | Bodo Möller bodo@openssl.org 

fingerprint: 3FD2 C7DB D3EA 28B7 BOC6 1B5D E9A7 C808 4A39 7EA2 
1FE8E023 | Andy Polyakov appro@openssl.org 

fingerprint: B652 F27F 2B8D 1B8D A78D 7061 BA6C DA46 1FE8 E023 
41C25E5D | Kurt Roeckx kurt@openssl.org 

fingerprint: E5E5 2560 DD91 C556 DDBD A5DO 2064 C536 41C2 5E5D 
5C51B27C | Rich Salz rsalz@openssl.org 

fingerprint: D099 684D C7C2 1E02 E14A BAFE F234 7945 5C51 B27C 
E18C1C32 | Geoff Thorpe geoff@openssl.org 

fingerprint: 1B3D F808 C221 D2A5 ED74  172F 0833 F510 E18C 1C32 
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Appendix B CMVP Test Procedure 


Instructions for building OpenSSL and performing the FIPS 140-2 and related algorithm tests on 
Linux®/Unix® Microsoft Windows® based platforms are given here. These instructions are 
primarily of interest to the CMVP testing laboratory performing the validation testing, or anyone 
wishing to verify that the executable library generates generates the same output for the algorithm 
tests performed by the testing laboratory. 


Note there is no requirement for end users or application developers to run these tests; this 
discussion is included for reference purposes to illustrate the algorithm testing performed by the 
CMVP test lab. Note this step requires a large directory tree of input test data files produced by the 
testing lab using a NIST provided tool (CAVS); several sets of input and response values can be 


found http://openssl.com/testing/validation-2.0/testvectors/. The file 


http://openssl.com/testing/validation-2.0/testvectors/tv.tar.gz 
contains a complete set of 259 test vector files with correct responses that can be used for a single 


comprehensive test. Note the number and format of these test vector files changes over time, so this 
set may not correspond exactly to what the CAVS tool currently produces. 


B.1 Building the Software - Linux/Unix 


1. Copy the OpenSSL distribution (openssl-fips-2.0.tar.gz) to a directory on the test 
system. Approximately 80Mb free space is needed for this file and the resulting work area. 


2. Perform the standard build. Use of a seript file or comparable means of capturing the output 
is highly recommended. 


gunzip -c openssl-fips-2.0.tar.gz | tar xf - 
cd openssl 


./config [no-asm] 
make 


... Where the no-asm option may or not be present depending on the platform. 
3. Run 


make build tests 
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to generate the standalone additional programs to support the testing process. To generate a 
single program that contains the functionality of fips_test_suite and the individual standalone 
algorithm test programs, run 
make build algvs 

to build the fips algvs program. This program is necessary for some platforms that do not 
provide a suitable command shell and for which the execution of many separate programs is 
awkward or difficult, and may be convenient in other circumstances. 
The fips algvs program can be used to execute specific tests, for instance 

fips algv fips test suite post 

fips algv fips dssvs pag "tv/reg/POGGen.reg" 

"tv/resp/PQGGen.rsp" 


or if given no command line options it will process the subcommands in a minimal shell script 
as generated by 


perl fipsalgtest.pl --dir-«testvectors» --minimal-script 
--generate-script-fipstests.sh perl --tprefix- 


which will produce a file fipstests. sh with the subcommands corresponding to each 
request file, e.g.: 


fips dssvs pqg "tv/req/PQGGen.req" "tv/resp/PQGGen.rsp" 


The fips algvs program supports the following command line options: 


-quiet suppress any progress output. 

-verbose echo full command lines of executed commands 
(default is to omit filenames) 

-script «filename» script to use, default is fipstests.sh 


In absence of any options it assumes a script file fipstests. sh should be read from the 
current directory. If the first argument doesn't begin with a '-' it is taken as the name of a sub 
program to run: 


fips aesavs 
fips algvs 

fips cmactest 
fips desmovs 
fips dhvs 
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fips_drbgvs 
fips_dsatest 
fips_dssvs 
fips_ecdhvs 
fips_ecdsavs 
fips_gcmtest 
fips_hmactest 
fips_randtest 
fips_rngvs 
fips_rsagtest 
fips_rsastest 
fips_rsavtest 
fips_shatest 
fips test suite 


Note that for future validations the fips algvs program will probably entirely replace the 
separate fips test suite and algorithm test driver programs. 


B.2 Algorithm Tests - Linux/Unix 


4. Add the subtree of test data to the distribution work area: 


ed fips 
unzip <zipfile of test vectors>.zip -d testvectors 


5. Run the FIPS 140-2 algorithm tests: 
perl fipsalgtest.pl --dir-testvectors 


This step runs the algorithm tests specific to the FIPS mode. Again a large amount of output 
will be generated. If an error occurs processing will be aborted. The output from the 
cryptographic tests will be compared against the response files already present in the test data 
and not permanently stored. This comparison automatically suppresses the whitespace and 
comment line differences and ignores the seven test vector files that are always different”. 


“Due to the nature of the cryptographic operations involved the following responses files will always be different: 
DSA 


KeyPair.rsp 

PQGGen.rsp DSA 
SigGen.rsp DSA 
SigGenl5.rsp RSA 
SigGenPSS.rsp RSA 
SigGenRSA.rsp RSA 
SigGenPSS.rsp RSA 


The special case cryptographic operations are listed in the associative array $verify specials tin the fipsalgvs.pl 
perl script. 
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To generate and preserve new response files use the --generate option: 


perl fipsalgtest.pl --dir-testvectors --generate 


directory tree under . / fips/: 


find testvectors/ -name '*.rsp' 


The tree of * . rsp files can also be extracted for comparison with another tree: 


find testvectors -name '*.rsp' | cpio -oc > rspl.cpio 


cd /tmp 

mkdir rspl rsp2 

cd rspl; cpio -ic « rspl.cpio 

cd ../rsp2; cpio -ic « rsp2.cpio 
diff -r . ../rspl 


If the only other differences are the commented date-time labels then the trees match: 


B.3 


diff -r ./testvectors/aes/resp/CBCGFSbox128.rsp \ 
../rspl/testvectors/aes/resp/CBCGFSbox128.rsp 

6c6 

< # Thu Mar 4 11:05:36 2004 

> 4 Fri Feb 20 12:21:24 2004 

diff -r ./testvectors/aes/resp/CBCGFSbox192.rsp \ 
../rspl/testvectors/aes/resp/CBCGFSbox192.rsp 

6c6 

< # Thu Mar 4 11:05:36 2004 


> $ Fri Feb 20 12:21:24 2004 


Building the Software - Windows 
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1. Copy the OpenSSL distribution (openssl-fips-2.0.tar.gz) to a directory on the test 
system. Approximately 80Mb free space is needed. 


2. Perform the standard build. 


cd openssl 
ms\do fips [no-asm] 
out32dllMfips test suite 


... Where the no-asm option may or not be present depending on the platform. 


B.4 Algorithm Tests - Windows 


3. This procedure is similar to that for Linux/Unix: 


cd fips 

unzip <zipfile of test vectors>.zip -d testvectors 
perl fipsalgtest.pl --win32 --dir-testvectors 
.\fipstests.bat 


There is no bundled zip/unzip command for most versions of Microsoft Windows, but many third 
party implementations are available, such as http://gnuwin32.sourceforge.net/packages/unzip.htm. 


B.5 FIPS 140-2 Test - All Platforms 


A test driver program has been provided to demonstrate both successful and failed power-up self- 
tests and the invocation of some basic cryptographic operations. This program was developed 
during the course of the FIPS 140-2 validation as a aid to the test lab evaluators. This test program, 
fips_test_suite, can be found in the ./test/ subdirectory. This program behaves the 
same for Linux/Unix and Windows; for Windows invoke as .\fips_test_suite instead of 
./fips_test_suite as shown in this example. 


1. When executed with no argument output similar to the full suite of algorithm tests is performed, 
producing the following output: 


$ FIPS-mode test application 
FIPS 2.0-dev unvalidated test module xx XXX xxxx 


DRBG AES-256-CTR DF test started 
DRBG AES-256-CTR DF test OK 
1. Non-Approved cryptographic operation test... 
a. Included algorithm (D-H)...... successful 
POST started 
Integrity test started 
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Integrity test OK 

DRBG AES-256-CTR DF test started 
DRBG AES-256-CTR DF test OK 
DRBG AES-256-CTR test started 
DRBG AES-256-CTR test OK 

DRBG SHA256 test started 

DRBG SHA256 test OK 

DRBG HMAC-SHA256 test started 
DRBG HMAC-SHA256 test OK 

DRBG P-256 SHA256 test started 
DRBG P-256 SHA256 test OK 

X9.31 PRNG keylen=16 test started 
X9.31 PRNG keylen=16 test OK 
X9.31 PRNG keylen=24 test started 
X9.31 PRNG keylen=24 test OK 
X9.31 PRNG keylen=32 test started 
X9.31 PRNG keylen=32 test OK 
Digest SHAl test started 

Digest SHA1 test OK 

Digest SHAl test started 

Digest SHAl test OK 

Digest SHAl test started 

Digest SHAl test OK 

HMAC SHA1 test started 

HMAC SHA1 test OK 

HMAC SHA224 test started 

HMAC SHA224 test OK 

HMAC SHA256 test started 

HMAC SHA256 test OK 

HMAC SHA384 test started 

HMAC SHA384 test OK 

HMAC SHA512 test started 

HMAC SHA512 test OK 

CMAC AES-128-CBC test started 
CMAC AES-128-CBC test OK 

CMAC AES-192-CBC test started 
CMAC AES-192-CBC test OK 

CMAC AES-256-CBC test started 
CMAC AES-256-CBC test OK 

CMAC DES-EDE3-CBC test started 
CMAC DES-EDE3-CBC test OK 
Cipher AES-128-ECB test started 
Cipher AES-128-ECB test OK 

CCM test started 

CCM test OK 

GCM test started 

GCM test OK 

XTS AES-128-XTS test started 
XTS AES-128-XTS test OK 

XTS AES-256-XTS test started 


Page 123 of 225 


User Guide - OpenSSL FIPS Object Module v2.0 


XTS AES-256-XTS test OK 
Cipher DES-EDE3-ECB test started 
Cipher DES-EDE3-ECB test OK 
Cipher DES-EDE3-ECB test started 
Cipher DES-EDE3-ECB test OK 
Signature RSA test started 
Signature RSA test OK 
Signature ECDSA P-224 test started 
Signature ECDSA P-224 test OK 
Signature ECDSA K-233 test started 
Signature ECDSA K-233 test OK 
Signature DSA test started 
Signature DSA test OK 
ECDH P-224 test started 
ECDH P-224 test OK 
POST Success 

2. Automatic power-up self test...successful 

3a. AES encryption/decryption...successful 

3b. AES-GCM encryption/decryption...successful 
Pairwise Consistency RSA test started 
Pairwise Consistency RSA test OK 
Pairwise Consistency RSA test started 
Pairwise Consistency RSA test OK 
Pairwise Consistency RSA test started 
Pairwise Consistency RSA test OK 

4. RSA key generation and encryption/decryption...successful 

5. DES-ECB encryption/decryption...successful 
Pairwise Consistency DSA test started 
Pairwise Consistency DSA test OK 

6. DSA key generation and signature validation...successful 

Ta. SHA-1 hash...successful 

7b. SHA-256 hash...successful 

7c. SHA-512 hash...successful 

7d. HMAC-SHA-1 hash...successful 

7e. HMAC-SHA-224 hash...successful 

7f. HMAC-SHA-256 hash...successful 

7g. HMAC-SHA-384 hash...successful 

7h. HMAC-SHA-512 hash...successful 

8a. CMAC-AES-128 hash...successful 

8b. CMAC-AES-192 hash...successful 

8c. CMAC-AES-256 hash...successful 

8e. CMAC-TDEA-3 hash...successful 

9. Non-Approved cryptographic operation test... 

a. Included algorithm (D-H)...successful as expected 

Pairwise Consistency RSA test started 
Pairwise Consistency RSA test OK 
Pairwise Consistency RSA test started 
Pairwise Consistency RSA test OK 
Pairwise Consistency RSA test started 
Pairwise Consistency RSA test OK 
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Generated 128 byte RSA private key 
BN key before overwriting: 
400e460169e1e37d8£415£e50c40£ab493185c17e99b76e123bc0£3d7d0c8b1£42881££7396b 
3ee388c3b973cece2d7d231109a7202016daf1e26caca9e704b9bffd9bd6151d61ab3050a82e 
78510abf2e450a6c57e9fb7db8a837f81fc93db0c6c95d090ac6752b8ac4ee51623ffcbd270b 
Oed28lebbe2e6a3a9d0a4012a991 BN key after overwriting: 
668Ad6314da4f25ca496a6f98e2f6986437be60f2Ad34880e8d08060263dd10a3bde7345ef99ed 
00e2edeedf£43albda7053c58b6474051bbaf9c9e5bf70a488a7b94d88c67fc9e16fc9e4bb231 
8836dc47282c8e41d3c35bc400949cd2d2b5e0ee0bd84ce8dffdb02dfc6c9528d0be43b0d95f 
ce6e979c561070e6da5a05b9e53e char buffer key before overwriting: 
4850f0a33aedd3af6e477f8302b10968 
char buffer key after overwriting: 
788fadb58c8163405e883a63550fd732 
10. Zero-ization... 
successful as expected 
11. Complete DRBG health check... 
DRBG AES-128-CTR DF test started 
DRBG AES-128-CTR DF test OK 
DRBG AES-192-CTR DF test started 
DRBG AES-192-CTR DF test OK 


(very long list of DRBG tests) 


DRBG P-521 SHA384 test started 
DRBG P-521 SHA384 test OK 
DRBG P-521 SHA512 test started 
DRBG P-521 SHA512 test OK 
successful as expected 
12. DRBG generation check... 
DRBG SHA1 test started 
DRBG SHA1 test OK 
DRBG SHA1 test started 
DRBG SHA1 test OK 


(very long list of DRBG tests) 


DRBG P-521 SHA512 test OK 

DRBG P-521 SHA512 test started 

DRBG P-521 SHA512 test OK 
successful as expected 


All tests completed with 0 errors 
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The nodh option skips the glacial and largely pointless DH test. 
The nodrbg option skips the slow full DRBG test 


The fullpost option gives a complete POST listing instead of induced failure and 
unexpected errors. The output is then much more verbose as it contains every successful test 
too. 


The fullerr option is useful for code tracing. Normally during the induced failure test 
library errors are not printed out. With this option the error codes corresponding to each 
operation are displayed showing the exact line and error code output. 


When executed with the post command line option only module initialization will be 
performed: 


$ test/fips test suite post 
FIPS-mode test application 
FIPS 2.0-dev unvalidated test module xx XXX xxxx 


DRBG AES-256-CTR DF test started 
DRBG AES-256-CTR DF test OK 

POST started 
Integrity test started 
Integrity test OK 
DRBG AES-256-CTR DF test started 
DRBG AES-256-CTR DF test OK 
DRBG AES-256-CTR test started 
DRBG AES-256-CTR test OK 
DRBG SHA256 test started 
DRBG SHA256 test OK 
DRBG HMAC-SHA256 test started 
DRBG HMAC-SHA256 test OK 
DRBG P-256 SHA256 test started 
DRBG P-256 SHA256 test OK 
X9.31 PRNG keylen=16 test started 
X9.31 PRNG keylen=16 test OK 
X9.31 PRNG keylen=24 test started 
X9.31 PRNG keylen=24 test OK 
X9.31 PRNG keylen=32 test started 
X9.31 PRNG keylen=32 test OK 
Digest SHAl test started 
Digest SHAl test OK 
Digest SHAl test started 
Digest SHAl test OK 
Digest SHAl test started 
Digest SHAl test OK 
HMAC SHAl test started 
HMAC SHAl test OK 
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HMAC SHA224 test started 
HMAC SHA224 test OK 
HMAC SHA256 test started 
HMAC SHA256 test OK 
HMAC SHA384 test started 
HMAC SHA384 test OK 
HMAC SHA512 test started 
HMAC SHA512 test OK 
CMAC AES-128-CBC test started 
CMAC AES-128-CBC test OK 
CMAC AES-192-CBC test started 
CMAC AES-192-CBC test OK 
CMAC AES-256-CBC test started 
CMAC AES-256-CBC test OK 
CMAC DES-EDE3-CBC test started 
CMAC DES-EDE3-CBC test OK 
Cipher AES-128-ECB test started 
Cipher AES-128-ECB test OK 
CCM test started 
CCM test OK 
GCM test started 
GCM test OK 
XTS AES-128-XTS test started 
XTS AES-128-XTS test OK 
XTS AES-256-XTS test started 
XTS AES-256-XTS test OK 
Cipher DES-EDE3-ECB test started 
Cipher DES-EDE3-ECB test OK 
Cipher DES-EDE3-ECB test started 
Cipher DES-EDE3-ECB test OK 
Signature RSA test started 
Signature RSA test OK 
Signature ECDSA P-224 test started 
Signature ECDSA P-224 test OK 
Signature ECDSA K-233 test started 
Signature ECDSA K-233 test OK 
Signature DSA test started 
Signature DSA test OK 
ECDH P-224 test started 
ECDH P-224 test OK 
POST Success 
Power-up self test successful 


$ 


Note this invocation is useful for a quick estimation of the performance impact of module 
initialization. 


To demonstrate the correct functioning of the integrity and KAT test failures a set of corruption 
tests are run automatically when the unqualified fips test suite option is specified. In 
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the implementation of the fips algvs utility these tests are specified in the 
fail list flist structure and a series of in-line tests which are traversed by the static 
function do fail all() at the point where the line 


13. Induced test failure check... 
is printed. Each specific test is preceded by one of the lines 


Testing induced failure of XXXX 
Testing operation failure with XXXX 


and the conclusion of all the corruption tests should end with the lines 


Induced failure test completed with 0 errors 
successful as expected 


Note the use of three static variables by the function do fail all() to specify the specific 
corruption tests to be performed. 


The individual tests in the order performed are: 


Integrity 
AES 

DES3 
AES-GCM 
AES-CCM 
AES-XTS 
Digest 

HMAC 

CMAC 

DRBG 

X9.31 PRNG 
RSA 

DSA 

ECDSA 

ECDH 

RSA keygen 
DSA keygen 
ECDSA keygen 
DRBG CPRNG 
DRBG entropy CPRNG 
X9.31 CPRNG 
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DRBG entropy failure 


This full set of corruption tests should appear as follows: 


13. 


Induced test failure check... 
Testing induced failure of Integrity test 
POST started 
Integrity test failure induced 
Integrity test failed as expected 
POST Failed 
Testing induced failure of AES test 
POST started 
Cipher AES-128-ECB test failure induced 
Cipher AES-128-ECB test failed as expected 
POST Failed 
Testing induced failure of DES3 test 
POST started 
Cipher DES-EDE3-ECB test failure induced 
Cipher DES-EDE3-ECB test failed as expected 
POST Failed 
Testing induced failure of AES-GCM test 
POST started 
GCM test failure induced 
GCM test failed as expected 
POST Failed 
Testing induced failure of AES-CCM test 
POST started 
CCM test failure induced 
CCM test failed as expected 
POST Failed 
Testing induced failure of AES-XTS test 
POST started 
XTS AES-128-XTS test failure induced 
XTS AES-128-XTS test failed as expected 
XTS AES-256-XTS test failure induced 
XTS AES-256-XTS test failed as expected 
POST Failed 
Testing induced failure of Digest test 
POST started 
Digest SHA1 test failure induced 
Digest SHA1 test failed as expected 
Digest SHA1 test failure induced 
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Digest SHA1 test failed as expected 
Digest SHA1 test failure induced 
Digest SHA1 test failed as expected 
POST Failed 
Testing induced failure of HMAC test 
POST started 
HMAC SHA1 test failure induced 
HMAC SHA1 test failed as expected 
HMAC SHA224 test failure induced 
HMAC SHA224 test failed as expected 
HMAC SHA256 test failure induced 
HMAC SHA256 test failed as expected 
HMAC SHA384 test failure induced 
HMAC SHA384 test failed as expected 
HMAC SHA512 test failure induced 
HMAC SHA512 test failed as expected 
POST Failed 
Testing induced failure of CMAC test 
POST started 
CMAC AES-128-CBC test failure induced 
CMAC AES-128-CBC test failed as expected 
CMAC AES-192-CBC test failure induced 
CMAC AES-192-CBC test failed as expected 
CMAC AES-256-CBC test failure induced 
CMAC AES-256-CBC test failed as expected 
CMAC DES-EDE3-CBC test failure induced 
CMAC DES-EDE3-CBC test failed as expected 
POST Failed 
Testing induced failure of DRBG test 
POST started 
DRBG AES-256-CTR test failure induced 
DRBG AES-256-CTR DF test failed as expected 
DRBG AES-256-CTR test failure induced 
DRBG AES-256-CTR test failed as expected 
DRBG SHA256 test failure induced 
DRBG SHA256 test failed as expected 
DRBG HMAC-SHA256 test failure induced 
DRBG HMAC-SHA256 test failed as expected 
DRBG P-256 SHA256 test failure induced 
DRBG P-256 SHA256 test failed as expected 
POST Failed 
Testing induced failure of X9.31 PRNG test 
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POST started 
X9.31 PRNG keylen=16 test failure induced 
X9.31 PRNG keylen=16 test failed as expected 
X9.31 PRNG keylen=24 test failure induced 
X9.31 PRNG keylen=24 test failed as expected 
X9.31 PRNG keylen=32 test failure induced 
X9.31 PRNG keylen=32 test failed as expected 
POST Failed 
Testing induced failure of RSA test 
POST started 
Signature RSA test failure induced 
Signature RSA test failed as expected 
POST Failed 
Testing induced failure of DSA test 
POST started 
Signature DSA test failure induced 
Signature DSA test failed as expected 
POST Failed 
Testing induced failure of ECDSA test 
POST started 
Signature ECDSA P-224 test failure induced 
Signature ECDSA P-224 test failed as expected 
POST Failed 
Testing induced failure of ECDH test 
POST started 
ECDH P-224 test failure induced 
ECDH P-224 test failed as expected 
POST Failed 
Testing induced failure of RSA keygen test 
POST started 
POST Success 
Pairwise Consistency RSA test failure induced 
Pairwise Consistency RSA test failed as expected 
RSA key generation failed as expected. 
Testing induced failure of DSA keygen test 
POST started 
POST Success 
Pairwise Consistency DSA test failure induced 
Pairwise Consistency DSA test failed as expected 
DSA key generation failed as expected. 
POST started 
POST Success 
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Testing induced failure of ECDSA keygen test 
Pairwise Consistency ECDSA test failure induced 
Pairwise Consistency ECDSA test failed as expected 

ECDSA key generation failed as expected. 

POST started 

POST Success 

Testing induced failure of DRBG CPRNG test 

DRBG continuous PRNG failed as expected 

POST started 

POST Success 

Testing induced failure of DRBG entropy CPRNG test 

DRBG continuous PRNG entropy failed as expected 

POST started 

POST Success 

POST started 

POST Success 

Testing induced failure of X9.31 CPRNG test 

X9.31 continuous PRNG failed as expected 

POST started 

POST Success 

Testing operation failure with DRBG entropy failure 

DSA key generated OK as expected. 

DRBG entropy fail failed as expected 

DSA signing failed as expected 

ECDSA key generation failed as expected. 

Induced failure test completed with 0 errors 

successful as expected 


So, the presence of the line 


Induced failure test completed with 0 errors 


for the block of tests beginning with the line 


Induced test failure check... 


is a readily observed indication that all corruption tests performed as expected. 


To demonstrate the module authentication one of four command line options may be given to 
specify the password value to be passed to FIPS module mode set (): 


nopass Null password 
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badpass Invalid password of sufficient length 
user The FIPS_AUTH_CRYPTO_USER password 
officer The FIPS_AUTH_CRYPTO_OFFICER password 


If none of those command line options are given the FIPS_AUTH_CRYPTO_USER password 
is used. Invocation with none or badpass will fail: 


$ test/fips test_suite badpass 
FIPS-mode test application 
FIPS 2.0-dev unvalidated test module xx XXX xxxx 


DRBG AES-256-CTR DF test started 

DRBG AES-256-CTR DF test OK 
ERROR :2D078097:1ib=45, func=120, reason=151:file=fips.c:line= 
300 
Power-up self test failed 


$ 


and invocation with user or officer will successfully perform the POST test. 


B.6 Testvector Data Files and the fipsalgtest.pl Utility 


The FIPS 140-2 test labs use CAVP provided Windows based software known as the “CAVS tool” 
to generate the test vector data files used for the algorithm tests. The algorithms desired are 
typically specified using forms proprietary to the specific test lab performing the testing. Non- 
proprietary facsimiles of those forms specifying the algorithms tests foe the 2.0 module validation 
can be found at http://openssl.com/testing/validation-2.0/forms/. 


The test lab uses the CAVS tools to generate a set of "request" files for which corresponding 
"response" files must be generated by the module (the IUT or Implementation Under test). The set 
of request files is typically delivered in a single zip or tar file containing a directory tree with 
arbitrary pathnames. The only constant is the names of the actual * . rsp response files of input 
data. Since matching filenames up by hand quickly becomes tedious we have developed a utility, 
fipsalgtest.pl, that will search through a directory hierarchy and identify the relevant test 
vector files. 


For the initial validation there were 257 unique file names with 2 duplicate names, for a total of 259 
files: 


Algorithm Number of *.req files 
AES 108 
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Algorithm Number of *.req files 
AES_GCM 6 
CCM 15 
CMAC 8 
DES 0 
DRBG 4 
DSA 5 
DSA2 5 
ECDSA 4 
ECDSA2 4 
HMAC 1 
KAS 1 
RNG 6 
RSA 9 
SHA 15 
TDES 66 
XTS 2 
Total 239 


In order to facilitate the processing of test vector data a series of utilities were developed, 
culminating in the fipsalgtest.pl program. This program searches a target directory for the 
known * . rsp files and generates a script referencing the actual pathnames for those files. That 
script can then be executed to perform the algorithm tests that generate the * . rsp result files. The 
fipsalgtest .pl program reports unrecognized duplicate * . rsp files and any files that were 
expected but not found. 


Testvector data sets are generally received as * . zip files, more rarely as *.tgz. Atypical 
pathname structure (for this validation) is as follows: 


./OSF 2464 Template 

./OSF 2464 Template/AES 

./OSF 2464 Template/AES/resp 

./OSF 2464 Template/AES/req 

./OSF 2464 Template/AES/req/CBCGFSbox128.req 
./OSF 2464 Template/AES/req/CFB128MMT192.req 
./OSF 2464 Template/AES/req/CBCVarKey192.req 
./OSF 2464 Template/AES/req/CFBlVarTxt256.req 
./OSF 2464 Template/AES/req/CBCMMT128.req 
./OSF 2464 Template/AES/req/CBCKeySbox256.req 
./OSF 2464 Template/AES/req/ECBVarTxt192.req 
./OSF 2464 Template/AES/req/CFB128VarKey256.req 
./OSF 2464 Template/AES/req/OFBVarTxt128.req 
./OSF 2464 Template/AES/req/CFB1MCT192.req 
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./OSF 2464 Template/AES/req/CBCVarKey128.req 
./OSF 2464 Template/AES/req/CFB8VarTxt128.req 
./OSF 2464 Template/AES/req/ECBMMT128.req 

./OSF 2464 Template/AES/req/CBCGFSbox192.req 
./OSF 2464 Template/AES/req/CFB128MCT192.req 
./OSF 2464 Template/AES/req/OFBMCT128.req 

./OSF 2464 Template/AES/req/CFB1GFSbox256.req 


Note directory names may contain embedded spaces. The data files will generally (though not 
necessarily) be carriage return-line feed delimited. 


If multiple platforms are involved in a validation the test vector files for several platforms may be 
interspersed in the same directory tree. We have also received test vector files for a single platform 
in multiple different * . zip files, so the fipsalgtest .pl program must be able to filter the 
relevant * . rsp files out of multiple subdirectories. 


The following fipsalgtest .pl options can be used to accommodate various representations of 
test vector files: 


fipsalgtest.pl: generate run CAVP algorithm tests 


--debug 
--dir=<dirname> 
--filter-«regexp» 
--onedir <dirname> 
--rspdir-«dirname» 


--tprefix-«prefix^ 


--ignore-bogus 
-—-ignore-missing 

-—-quiet 

--quiet-bogus 
-—-quiet-missing 

-—-generate 
-—-generate-script-«filename» 
--minimal-script 


——win32 
--compare-all 
-—-list-tests 
--mkdir-«cmd» 
--notest 
--rm-«cmd» 
-—-script-tprefix 
-—-enable-«alg» 
--disable-«alg» 
Where «alg» can be one of: 
aes-ccm 
rand-aes 
ecdsa 


Enable debug output 

Optional root for *.req file search 

Regex for input files of interest 

Assume all components in current directory 

Name of subdirectories containing *.rsp 
files, default "resp" 

Pathname prefix for directory containing test 
programs 

Ignore duplicate or bogus files 

Ignore missing test files 

Shhh.... 

Skip unrecognized file warnings 

Skip missing request file warnings 

Generate algorithm test output 

Generate script to call algorithm programs 

Simplest possible output for 
-—-generate-script 

Win32 environment 

Verify unconditionally for all tests 

Show individual tests 

Specify "mkdir" command 

Exit before running tests 

Specify "rm" command 

Pathname prefix for --generate-script output 

Enable algorithm set «alg». 

Disable algorithm set «alg». 


(disabled by default) 
(enabled by default) 
(disabled by default) 
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hmac (enabled by default) 
dh (disabled by default) 
aes-cfbl (disabled by default) 
ecdh (disabled by default) 
des3-cfbl (disabled by default) 
drbg (disabled by default) 
des3 (enabled by default) 
dsa (enabled by default) 
dsa-pqgver (disabled by default) 
rsa-pssO (disabled by default) 
sha (enabled by default) 
aes (enabled by default) 
dsa2 (disabled by default) 
aes-gcm (disabled by default) 


rsa-pss62 
cmac 


(enabled by default) 
(disabled by default) 


aes-xts (disabled by default) 
rsa (enabled by default) 
v2 (enabled by default) 


rand-des2 


(disabled by default) 


perl fipsalgtest.pl --dir-testvectors --generate 
to generate the * . rsp files for submission to the test lab. 


Subsequently running fipsalgtest .pl without the --generate option will compare the 
generated output with the previously existing * . rsp files, and thus provides a comprehensive 
(though unofficial) check of the algorithm tests. 


Individual algorithm tests can be selectively specified with options of the form --enable-xxx or 
--disable-xxx where xxx is one of the «alg» algorithm specifications 


The --ignore-bogus and --ignore-missing options suppress the error exit if the target 
test vector directory contains more or fewer * . rsp files than expected (a not uncommon 
occurrence in validation testing. 


For target platforms that do not support a perl interpreter, but which do provide a basic command 
line shell, a simple shell script can be generated, for instance: 


perl ./fips/fipsalgtest.pl --generate-script-fipstest.sh --tprefix-./test/ 


will create a file fipstest.sh script file that successively invokes each of the algorithm test driver 
programs with the appropriate input and output file names: 


#!/bin/sh 
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# Test vector run script 
# Auto generated by fipsalgtest.pl script 
# Do not edit 


echo Running Algorithm Tests 
RM=" rm -rf"; 


MKDIR="mkdir"; 
TPREFIX=./test/ 


echo "Running DSA tests" 
SRM "./testvectors/tv/OSF 2464 Template/DSA/resp" 
SMKDIR "./testvectors/tv/OSF 2464 Template/DSA/resp" 


echo " running PQGGen test" 

S(TPREFIX)fips_dssvs pag 
"./testvectors/tv/OSF 2464 Template/DSA/req/PQGGen.req" 
"./testvectors/tv/OSF 2464 Template/DSA/resp/PQGGen.rsp" 
echo " running KeyPair test" 
S(TPREFIX)fips dssvs keypair 
"./testvectors/tv/OSF 2464 Template/DSA/req/KeyPair.req" 
"./testvectors/tv/OSF 2464 Template/DSA/resp/KeyPair.rsp" 
echo " running SigGen test" 
S(TPREFIX)fips dssvs siggen 
"./testvectors/tv/OSF 2464 Template/DSA/req/SigGen.req" 
"./testvectors/tv/OSF 2464 Template/DSA/resp/SigGen.rsp" 
echo " running SigVer test" 
S(TPREFIX)fips dssvs sigver 
"./testvectors/tv/OSF 2464 Template/DSA/req/SigVer.req" 
"./testvectors/tv/OSF 2464 Template/DSA/resp/SigVer.rsp" 
echo " running PQGVer test" 
S(TPREFIX)fips dssvs pagver 
"./testvectors/tv/OSF 2464 Template/DSA/req/PQGVer.req" 
"./testvectors/tv/OSF 2464 Template/DSA/resp/PQGVer.rsp" 


For very simple shells the --minimal-script option will omit use of the rm and mkdir 
commands to manage the output directories, in which case the empty req subdirectories will need 
to be created beforehand. 


To process only a subset of the test vectors file, use the -—-filter=XXX option to recognize only 
certain pathnames and the --disable-all --enable-xxx options to enable processing of 
only the algorithm(s) in that selected set for files. For instance: 


perl ./fips/fipsalgtest.pl --generate-script-fipstestsha.sh --tprefix-./test/ 
--disable-all --enable-sha --dir-testvectors --filter-SHA 
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B.6 Documentation 


This section discussed the major components of the documentation set for a FIPS 140-2 validation. 
Finite State Model 


FIPS 140-2 validation requires a Finite State Module (FSM), something that doesn't make much 
sense for a general purpose cryptographic library. This cosmetic requirement is satisfied by an 
arbitrary generic diagram and possibly an associated listing or spreadsheet of the states and 
transitions. Each test lab will typically have a generic template or sample that can be used. The 
FSM used for this validation can be found in the two files: 


http://openssl.com/testing/validation-2.0/docs/FSM .pdf 
http://openssl.com/testing/validation-2.0/docs/FSM_main.pdf 


The FSM does not contain any information of actual technical value. 
Vendor Evidence Document 


The test lab must answer the assertions in the Derived Test Requirements (DTR) document 
(Reference 4). Some labs chose to do so by directly listing all of the assertions with corresponding 
responses in the order those assertions appear in the DTR. Others respond to the assertions in 
analysis document structured along more functional lines with many of the redundant an 
overlapping assertions grouped together with a consolidated response. As with the formal test 
report (see following section) the test lab will typically want to claim this document as proprietary. 
The relevant content of the analysis document for this validation has been extracted as Appendix E. 


Formal Test Report 


The test lab submits a formal test report document to the CMVP. Test labs are uniformly adverse to 
releasing this document but can usually be persuaded to do so under a non-disclosure agreement 
(such release should be negotiated prior to executing a contract). OSF has seen some test reports 
but cannot publish them due to the non-disclosure restrictions. Note that those test reports would be 
of limited value as different test labs can take significantly different approaches to presenting the 
same module to the CMVP. FIPS 140-2 validation is a highly subjective process and each test lab, 
and even different reviewers at the CMVP, have distinctive styles. Mixing components from 
multiple submissions, even of exactly the same software, would result in significant discrepancies 
and conflicts. 
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Appendix C Example OpenSSL Based Application 


This example shows a simple application using OpenSSL cryptography which will qualify as FIPS 
140-2 validated when built and installed in accordance with the procedures in $5. In this 
application all cryptography is provided through the FIPS Object Module and the FIPS mode 
initialization is performed via the FIPS mode set () call. The command generates a HMAC- 
SHA-1 digest of an input stream or a file, using the same arbitrary key as the OpenSSL FIPS 
Module file integrity check: 


$ ./fips hmac —v fips hmac.c 

FIPS mode enabled 
8£2c8e4£60607613471c11287423£8429b068eb2 
$ 

$ ./hmac « hmac.c 
8£2c8e4£60607613471c11287423£8429b068eb2 
$ 


Note this sample command is functionally equivalent to: 


env OPENSSL FIPS-1 openssl -hmac etaonrishdlcupfm hmac.c 
or 
openssl dgst -fips-fingerprint filename.tar.gz 


for an openss1 command built from a FIPS capable OpenSSL distribution. The OPENSSL_FIPS=1 
environment variable enables FIPS mode for a openss1 command generated from a FIPS capable 
OpenSSL distribution. 


C.1 Native Compilation of Statically Linked Program 


Makefile 


CC = gee 

OPENSSLDIR = /usr/local/ssl 

LIBCRYPTO = $(OPENSSLDIR) /lib/libcrypto .a 
INCLUDES = -I$(OPENSSLDIR)/include 

CMD = fips hmac 

OBJS = $(CMD) .o 


$ (CMD): $(0BJS) 
FIPSLD_CC=$(CC) $ (OPENSSLDIR) /bin/fipsld -o $(CMD) $(OBJS) \ 
$ (LIBCRYPTO) 


$(OBJS): $(CMD).c 
$ (CC) -c $(CMD).c $ (INCLUDES) 
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clean: 
rm $ (OBJS) 


Note the line 
$ (OPENSSLDIR) /fips/fipsld -o $(CMD) $(0BJS) 


uses the fipsld command from the distribution source tree to perform the function of verifying 
the fipscanister.o digest and generating the new embedded digest in the application 
executable object. 


Source File 


/* 
Sample application using FIPS mode OpenSSL. 


This application will qualify as FIPS 140-2 validated when built, 
installed, and utilized as described in the "OpenSSL FIPS 140-2 
Security Policy" manual. 


This command calculates a HMAC-SHA-1 digest of a file or input data 
stream using the same arbitrary hard-coded key as the FIPS 140-2 
source file build-time integrity checks and runtime executable 
file integrity check. 

*/ 


#include <stdio.h> 
#include <string.h> 
#include «openssl/hmac.h» 


static char label[] = "@(#)FIPS approved SHAl HMAC"; 


static void dofile(FILE *fp) 
{ 
HMAC CTX ctx; 
unsigned char hmac value[EVP MAX MD SIZE]; 
int hmac len, i; 
char key[] = "etaonrishdlcupfm"; 
char buf[256]; 


/* Initialise context */ 

HMAC CTX init(&ctx); 

/* Set digest type and key in context */ 

HMAC Init ex(&ctx, key, strlen(key), EVP shal(), NULL); 

/* Process input stream */ 

while(i = fread(buf,sizeof(char),sizeof(buf),fp)) ( 
if(!HMAC Update(&ctx, buf, i)) exit(3); 

) 
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/* Generate digest */ 
if(!HMAC Final(&ctx, hmac value, &hmac len)) exit (4); 
HMAC CTX cleanup(&ctx); 


/* Display digest in hex */ 

for(i = 0; i < hmac len; i++) printf ("%02x", hmac_value[i]); 
printf ("Nn"); 

return; 


) 


main(int argc, char *argv[]) 
{ 
char *opt = NULL; 
int verbose = 0; 
int fipsmode = 1; 
FILE *fp = stdin; 
int i; 


/* Process command line arguments */ 
i = 0; 
while(++i < argc) { 
opt = argv[i]; 
if (!strcmp (opt,"-v")) verbose = 1; 
else if (!strcmp(opt,"-c")) fipsmode = 0; 
else if ('-' == opt[0]) ( 
printf ("Usage: $s <filename>\n", argv[0]); 
puts ("Options:"); 
puts ("\t-c\tUse non-FIPS mode"); 
puts("Nt-vNtVerbose output"); 
exit (1); 
} 
else break; 


} 


/* Enter FIPS mode by default */ 
if (fipsmode) { 
if(FIPS mode set (1)) { 
verbose ££ fputs ("FIPS mode enabled\n", stderr); 


} 
else { 
ERR load crypto strings(); 
ERR print errors fp(stderr); 
exit (1); 
} 
} 
if (i >= argc) { 
dofile (fp); 
} 
else { 
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while(i < argc) ( 
opt = argv[i]; 


if ((fp = fopen(opt,"rb")) == NULL) ( 
fprintf (stderr, "Unable to open file \"%s\"\n", opt); 
exit (1); 
) 
dofile(fp); 
fclose(fp); 
itt; 


) 
} 


exit (0) ; 
} 


C.2 Cross-compilation of "FIPS capable” Shared OpenSSL Libraries 


Here is an example of building and executing the same example program on an Android 4.0 device 
using a shared 1iberypto library. The NDK and SDK are from the files 


android-sdk r18-linux.tgz 
android-ndk-r7c-linux-x86.zip 


downloaded from http://developer.android.com/sdk/index.html. 


# Establish the cross-compilation environment 

export ANDROID NDK-$PWD/android-ndk-r7c 

export FIPS SIG-$PWD/openssl-fips-2.0/util/incore 

PATH-$ANDROID NDK/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux- 
x86/bin:$PATH 

export PATH 

export MACHINE-armv71 

export RELEASE-2.6.39 

export SYSTEM-android 

export ARCH-arm 

export CROSS COMPILE-"arm-linux-androideabi-" 

export ANDROID DEV-"$ANDROID NDK/platforms/android-14/arch-arm/usr" 
export HOSTCC=gcc 


# Build the FIPS module 

gunzip -c openssl-fips-2.0.tar.gz | tar xf - 
cd openssl-fips-2.0/ 

./config 

make 

make install INSTALLTOP=SPWD/../fips 

ed .. 
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# Build the "FIPS capable" OpenSSL 

gunzip -c openssl-1.0.1c.tar.gz | tar xf - 

cd openssl-1.0.1c/ 

./config fips shared --with-fipsdir-$PWD/../fips 
make depend 

make 


# Build the example program 

arm-linux-androideabi-gcc -o fips hmac fips hmac.c \ 
-Iopenssl-1.0.1c/include/ -Lopenssl-1.0.1c/ -lcrypto -Iopenssl-1.0.1c \ 
-Iandroid-ndk-r7c/platforms/android-14/arch-arm/usr/include \ 
-Bandroid-ndk-r7c/platforms/android-14/arch-arm/usr/lib 


# Copy the program and shared library to the Android device 
./android-sdk-linux/platform-tools/adb push fips hmac /data/local/tmp/ 
./android-sdk-linux/platform-tools/adb push openssl- 
1.0.1c/libcrypto.so.1.0.0 /data/local/tmp/ 


# Execute the program on the Android device 
./android-sdk-linux/platform-tools/adb push fips hmac shell 
cd /data/local/tmp 

LD LIBRARY PATH-openssl-1.0.1c ./fips hmac -v fips hmac.c 
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Appendix D FIPS API Documentation 


D.1 


NAME 


FIPS Mode 


FIPS mode - NIST FIPS 140-2 Approved mode of operation 


DESCRIPTION 


When built with the fips config option in accordance with some additional 
procedural requirements the OpenSSL FIPS Object Module can be used to satisfy 
requirements for FIPS 140-2 validated cryptography. 


OVERVIEW 


NOTES 


The OpenSSL FIPS Object Module must be built with the fips config option. The 
application must call FIPS mode set() to enable FIPS mode. When in FIPS mode only 
the FIPS approved encryption algorithms 

are usable: 


+RSA 
+DSA 
+3DES in CBC, (CFB1), CFB8, CFB64, ECB, OFB modes 
+DH 
+AES in CBC, (CFB1), CFB8, CFB128, ECB, OFB modes with 128/192/256 bit keys 


+SHA-1, SHA-2 


+HMAC 


Other non-FIPS approved algorithms such a Blowfish, MD5, IDEA, RC4, etc. are 
disabled in FIPS mode. 


To determine the mode of operation in a running program, an application can call 
FIPS mode(3). A non-zero return indicates FIPS mode; a 0 indicates non-FIPS mode. 


If the FIPS power-up self-test fails subsequent cryptographic operations are disabled 
and the application will have to exit. 


To be considered FIPS 140-2 validated the OpenSSL FIPS Object Module must use the 
validated version of the FIPS specific OpenSSL source code. 


While most platforms and applications can use the OpenSSL FIPS Object Module to 

satisfy NIST requirements for FIPS 140-2 validated cryptography there are additional 
additional requirements beyond the call to FIPS mode set(). A more complete discussion 
of the OpenSSL FIPS mode can be found in the OpenSSL FIPS 140-2 Security Policy which 
can be found at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1747.paf. 


Information about FIPS 140 can be found at http://esre.nist.gov/groups/STM/emvp/. 
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3DES is also known as TDEA, or Triple Data Encryption Algorithm. 
The power-up self-test can take a significant amount of time on slower systems. 


HISTORY 


FIPS mode support was introduced in version 0.9 of OpenSSL. 


SEE ALSO 


FIPS mode set(3), FIPS_mode (3) 


D.2 FIPS mode set(), FIPS selftest() 


NAME 

FIPS mode set, FIPS selftest - perform FIPS power-up self-test 
SYNOPSIS 

#include «openssl/crypto.h» 

int FIPS mode set(int ONOFF) 

int FIPS selftest (void) 
DESCRIPTION 


FIPS mode set() enables the FIPS mode of operation for applications 

that have complied with all the provisions of the OpenSSL FIPS 140-2 Security 
Policy. Successful execution of this function call with non-zero ONOFF is the 

only way to enable FIPS mode. After verifying the integrity of the executable 
object code using the stored digest FIPS mode set() performs the power-up self-test. 


When invoked with ONOFF of zero FIPS mode set() exits FIPS mode. 


To determine the mode of operation in a running program, an application can call 
FIPS mode(3). A non-zero return indicates FIPS mode; a 0 indicates non-FIPS mode. 


FIPS selftest() can be called at any time to perform the FIPS power-up self-test. 


If the power-up self-test fails subsequent cryptographic operations 
are disabled. The only possible recovery is a successful re-invocation of 
FIPS mode set() which is unlikely to work unless the original path was incorrect. 
RETURN VALUES 
A return value of 1 indicates success, 0 failure. 
SEE ALSO 
FIPS mode(3), ERR get error(3) 
NOTES 
FIPS mode set() and FIPS selftest() were formerly included with <openssl/fips/fips.h>. 


HISTORY 


FIPS support was introduced in version 0.9 of OpenSSL. 
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D.3 FIPS model) 


NAME 

FIPS mode - returns the current FIPS mode of operation. 
SYNOPSIS 

#include «openssl/crypto.h» 

int FIPS mode () 
DESCRIPTION 


FIPS mode () is used to determine the FIPS mode of operation of the running program. 


FIPS mode() currently returns 1 to indicate FIPS mode. Future return values might include 
to indicate exclusive use of the NSA's Suite B algorithms. 


RETURN VALUES 
A return code of non-zero indicates FIPS mode, 0 indicates non-FIPS mode. 
SEE ALSO 
FIPS mode set (3) 
NOTES 
FIPS mode() was formerly included with <openssl/fips/fips.h>. 


HISTORY 


FIPS support was introduced in version 0.9 of OpenSSL. 


D.4 Error Codes 


In order to minimize the size of the FIPS module only numeric error codes are returned. When 
used in conjunction with a FIPS capable OpenSSL distribution these numeric codes will 
automatically be converted to the usual text format for display, but the FIPS specific standalone 
utilities print out numerical error codes. These can be interpreted with the openssl errstr 
command or by checking the source file at the referenced location: 


$ ../util/shlib wrap.sh ./fips shatest 
ERROR:2d06c071:1ib=45, func=108, reason=113:file=fips.c:line=274:1,129d0 
5 

$ openssl errstr 2d06c071 

error:2D06C071:FIPS routines:FIPS mode set:unsupported platform 

5 


These error codes are defined in the include file fips_err.h. 
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The FIPS_mode_ set () call or other function calls in FIPS mode can return any of the following 


errors: 


Return Code 


Meaning and Comment 


CRYPTO R FIPS MODE NOT SUPPORTED 


“fips mode not supported” 
You likely linked against a non-FIPS Capable library. Ensure 
‘config fips «options? was executed when configuring. 


FIPS_R CANNOT READ EXE 


"cannot read exe" 


FIPS R CANNOT READ EXE DIGEST 


"cannot read exe digest" 


FIPS R CONTRADICTING EVIDENCE 


"contradicting evidence" 


FIPS_R EXE DIGEST DOES NOT MATCH 


"exe digest does not match" 


FIPS R FINGERPRINT DOES NOT MATCH 


"fingerprint does not match" 
The integrity test has failed. 


FIPS R FINGERPRINT DOES NOT MATCH - 
NONPIC RELOCATED 


"fingerprint does not match nonpic relocated" 

This Microsoft Windows specific error indicates that there 
might be a DLL address conflict which needs to be addressed 
by re-basing the offending DLL. 


FIPS R FINGERPRINT DOES NOT MATCH - 
SEGMENT ALIASING 


"fingerprint does not match segment aliasing" 

This error is returned when a defective compiler has merged 
. rodata (read-only) and . data (writable) segments. This 
situation effectively degrades the read-only status of constant 
tables and leaves them without hardware protection, thus 

jeopardizing the FIPS mode of operation. 


FIPS R FIPS MODE ALREADY SET 


"fips mode already set" 


FIPS R INVALID KEY LENGTH 


"invalid key length" 


FIPS R KEY TOO SHORT 


"key too short" 


FIPS R NON FIPS METHOD 


"non fips method" 
Attempted non FIPS-compliant DSA usage. 


FIPS R PAIRWISE TEST FAILED 


"pairwise test failed" 
One or more of the algorithm pairwise consistency tests has 
failed. 


FIPS R RSA DECRYPT ERROR 


"rsa decrypt error" 


FIPS R RSA ENCRYPT ERROR 


"rsa encrypt error" 


FIPS_R SELFTEST FAILED 


"selftest failed" 
One or more of the algorithm known answer tests has failed. 


FIPS_R TEST FAILURE 


"test failure" 


FIPS R UNSUPPORTED PLATFORM 


"unsupported platform" 
Indicates the validity of the digest test is unknown for the 
current platform. 
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AppendixE Platform Specific Notes 


Note: the material present in this appendix for earlier versions of this document has been removed 
and relocated to http://www.openssl.com/fips/tech/. 


E.1 Apple OS X Support 


<TBD> 
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E.2 Apple ¡OS Support 


Sprint > 12:07 PM 


OpenSSL fully supports building the FIPS Object Module 
and FIPS Capable library for iOS devices. There are five 
logical steps to build the OpenSSL FIPS Object Module 
and FIPS Capable Library for use in an Xcode/1OS project . 
The steps are outlined below: 


FIPS Program Inspector 
Acquire the required files 


h FIPS Premain 

2. Build the Incore utility begin, end] 

3. Build the FIPS Object Module Data: 0x036060, 0x0419a0 
4. Build the FIPS Capable Library Text: 0x004cac, 0x02b524 
5. Create an Xcode Project 


FIPS Fingerprint 
The procedures for each logical step are detailed below. The [embedded, calculated] 
sample Xcode project is offered at the end of the chapter. c3cc98e5a0770adaf2864cbba 


c3cc98e5a0770adaf2864cbba... 


FIPS mode [on GQ) 


Acquire Required Files 


First, obtain the base files from Illustration 1: OpenSSL FIPS 
http://www.openssl.org/source/: Sample Program 


openssl-1.0.1c.tar.gz 


openssl-fips-2.0.1.tar.gz 


Next, acquire the auxiliary files, which can be obtained from 
http://openssl.com/fips/2.0/platforms/1os/: 


setenv-reset.sh 
setenv-darwin-i386.sh 
setenv-ios-11.sh 


ios-incore-2.0.1.tar.gz 
In addition to the required core files listed above, http://openssl.com/fips/2.0/platforms/ios/ 
includes a sample program: 


fips-pi.tar.gz 


openssl-fips-2.0.1.tar.gz includes the FIPS Object Module. 


Page 149 of 225 


User Guide - OpenSSL FIPS Object Module v2.0 


openssl-1.0.1c.tar.gz has the FIPS Capable OpenSSL library. 


ios-incore-2.0.1.tar.gz contains OS X and iOS specific Incore utility to determine the 
object code digest. 


setenv-darwin-i386.sh and setenv-ios-11.sh are used to set the proper 
environments for the task at hand, while setenv-reset . sh is used to reset the environment. 


Note: as of this writing (January, 2013), the scripts have a PWD dependency and do not 
alert the user of failures such as missing or errant paths. I was not able to get 


hardened/updated scripts placed on web for download. Please accept my sincerest 
apologies (JW.). 


After collecting the required files, your working directory will look similar to below. 


Ill 
3 


E All My Files | d | 

"€ AirDrop Gz —_ cz — 

y Applications ios- openssi-1.0.1c openssl-1.0.1c.tar. openssl-fips-2.0.1 
E Desktop incore-2.0.1.tar.gz gz 

[B Documents | N S N S 

© Downloads 

H Movies GZ SHELL SHELL SHELL 

J Music openssi- setenv-darwin.sh setenv-ios.sh setenv-reset.sh 
e e fips-2.0.1.tar.gz 

(©) Pictures 


Illustration 2: Working Directory under Finder 


After acquiring the files, perform the following in the working directory to remove quarantine bit 
and ensure the execute bit is set: 


$ xattr -r -d "com.apple.quarantine" *.tar.gz *.sh 
$ chmod +x *.sh 


Build the Incore Utility 
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The Incore utility is a native application used to embed the FIPS Object Module's fingerprint in the 
ARM library. Building Incore is a two step process — first, build a native version of 
libcrypto.a, and then build Incore using the previously built native libcrypto.a. 


To compile the incore_macho utility for the native platform, perform the following steps: 


$ rm -rf openssl-fips-2.0.1/ (delete old artifacts) 
$ tar xzf openssl-fips-2.0.1.tar.gz (unpack fresh files) 
$ tar xzf ios-incore-2.0.1.tar.gz 

$ . /setenv-reset.sh (note the leading dot ".") 
$ ./setenv-darwin-i386.sh (note the leading dot ".") 
$ cd openssl-fips-2.0.1/ (perform ‘ed’ after setenv) 
$ ./config (several screens of output) 
$ make (build libcrypto.a, lots of output) 
$ cd i0S/ (switch to incore's subdirectory) 
$ make (build incore macho, lots of output) 


Note: as of this writing (January, 2013), setenv-darwin-i386. sh could silently fail due to 
PWD dependencies. Please execute the ' env" command and verify the paths placed in the 
environment by the script. 


Confirm the utility works: 
$ ./incore macho 


usage: 
./incore macho [--debug] [-exe|-dso] executable 


If the utility does not work, delete the openss1-fips-2.0.1/ directory and start over. 


Once the utility has been verified on the native platform, install the incore macho utility in a 
location on path, such as /usr/local/bin. The instructions below offer a second choice, and 
place incore macho in your home directory. 


$ mkdir "SHOME/bin" 


$ cp incore macho "SHOME/bin" 
$ PATH-"$HOME/bin":$PATH 
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Finally, delete the openss1-fips-2.0.1/ directory in preparation for the ARM build of the 
FIPS Capable library. This is done to keep cross contamination to a minimum since openss1- 
fips-2.0.1/ is essentially reused. 


$ cd .. 
$ rm -rf openssl-fip-2.0.1/ 


This instructions from this point assume the build environment has been prepared, including the 
creation of the incore macho utility, as documented in the previous section, and that 
incore macho is on path. 


Build the FIPS Object Module 


This section of the document will guide you through the creation of the FIPS Object Module. The 
Module is governed by the FIPS 140-2 program requirements and you cannot deviate from the 
Security Policy during any stage during handling, from acquisition, through building, to 
installation. In case of a discrepancy between this document and the Security Policy, the Security 
Policy will prevail. 


While these commands look similar to those recently executed for the generation of the 
incore macho utility, there are subtle differences. This time you are cross-compiling for the an 
iOS device. 


While it is not readily apparent, the iOS tools used via IOS TOOLS environmental variable are 
available from ios—incore-2.0.1.tar.gz, so you must unpack it again. The tools unpack 
into openssl-fips-2.0.1/. 


$ rm -rf openssl-fips-2.0.1/ (delete old artifacts) 
$ tar xzf openssl-fips-2.0.1.tar.gz (unpack fresh files) 
$ tar xzf  ios-incore-2.0.1.tar.gz (unpack fresh files) 
$ cd openssl-fips-2.0.1/ (perform ‘ed’ first) 
$. ../setenv-reset.sh (note the leading dot ".") 
Ss. ../setenv-ios-11.sh (note the leading dot ".") 
$ llvm-gcc -v (verify expected compiler) 


Using built-in specs. 

Target: i686-apple-darwin10 

Configured with: /private/var/tmp/llvmgcc42_Embedded/ 
llvmgcc42 Embedded-2377-4/src/configure 
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gcc version 4.2.1 (Based on Apple Inc. build 5658) 
(LLVM build 2377.00) 


Note: as of this writing (January, 2013), setenv-ios-11. sh could silently fail due to 
PWD dependencies. Please execute the ^ env? command and verify the paths placed in 
the environment by the script. 


The output of interest from 11vm-gcc -v are (1) 11vm-gocc is on path; (2) gee version 4.2.1; 
and (3) the compiler is for an embedded platform. 


At this point you are ready to commence the standard FIPS canister build for the target platform. 
Note that “fips canister” is implied, so there is no need for either ./config 


fipscanisterbuild or ./config fips (nor is it allowed by the Security Policy). 


$ ./config (several screens of output) 
$ make (lots of output) 


Confirm the binaries are for the iOS target device: 


$ lipo -info ./fips/fipscanister.o 
Non-fat file: ./fips/fipscanister.o is architecture: armv7 


After confirming the target architecture, complete the installation procedure by performing an 
install: 


$ sudo make install 
The default installation directory is /usr/local/ssl/Release-iphoneos/. 
After installation, delete the openss1-fips-2.0.1/ directory since its no longer needed: 
$ rm -rf openssl-fips-2.0.1/ 
Recall from Section 2.4.2 Object Module (Link Time) Integrity that applications link against 
libcrypto.a, and not directly to fipscanister.o. You will build liberypto.a and 


libssl.a next in Build the FIPS Capable Library®. 


Build the FIPS Capable Library 


This section of the document will guide you through the creation of the The FIPS Capable Library. 
The capable library is a standard OpenSSL distribution that is “FIPS Aware”. The “aware” library 
handles all the details of operation while in FIPS mode after you successfully call 

FIPS mode set () (see D.2 FIPS mode set(), FIPS selftest()). If you don't call 


“There is some hand waiving here, but the details are not important at the moment for these procedures. 
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FIPS mode set (), the library will still operate as expected; but it will not be using validated 
cryptography. 
Recall the FIPS Object Module is governed by the FIPS 140-2 program requirements, and you 


could not deviate from the Security Policy. The FIPS Capable Library does not endure the same 
requirements, and you are free to modify the environment and sources within reason. 


To build the FIPS Capable library, you must issue ./config fips, but other options are up to 
you. Some suggested options for configure include: 


Option Comment 

--openssldir Base of the OpenSSL installation. Default value is 
--openssldir-/usr/local/ssl/Release-iphoneos 

--with-fipsdir Location of fipscanister.o, if not located at /usr/local/ssl/Release- 
iphoneos/lib. 

-no-sslv2 Disable SSLv2. SSLv2 is defective”! 

-no-sslv3 Disable SSLv3. SSLv3 is defective? 

-no-comp Disable compression independent of zlib. Compression 1s known to leak session 
information via CRIME attacks? 

-no-shared Disable shared library output. Apple only allows static linking, and dynamic 
linking is not supported on iOS. 

-no-dso Disable the OpenSSL DSO API (the library offers a shared object abstraction 
layer). 108 only uses static linking. 

-no-hw Disable hardware support. 

-no-engines Disable engine support. 


To begin, clean old artifacts and set the environment for cross compilation. 


$ rm -rf openssl-1.0.1c/ (delete old artifacts) 
$ tar xzf openssl-1.0.1c.tar.gz (unpack fresh files) 
$ cd openssl-fips-1.0.1c/ (perform ‘ed’ first) 
$. ../setenv-reset.sh (note the leading dot ".") 
$. ../setenv-ios-11.sh (note the leading dot ".") 


Bruce Schneier and David Wagner, Analysis of the SSL 3.0 Protocol, www.schneier.com/paper-ssl-revised.pdf 

“Loren Weith, Differences Between SSLv2, SSLv3, and TLS, http://www.yaksman.org/-lweith/ssl.pdf 

$$ Mozilla's NSS accidentally disabled compression long before CRIME attacks due to compile/link conflicts 
(https://bugzilla.mozilla.org/show_bug.cgi?id=580679). Mozilla's Firefox did not support compression on clients. Many other 
browsers, such as Android (com.android.browser), did not support compression. 
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Next, configure and make the FIPS Capable library, where you pick your favorite options. No 


options are also acceptable: 


$ ./config fips 
$ make «options» 


«options» 


Confirm the binaries are for the iOS target device: 


$ lipo -info ./libcrypto.a 


(several screens of output) 
(lots of output) 


./libssl.a 


Non-fat file: ./libcrypto.a is architecture: armv7 
Non-fat file: ./libssl.a is architecture: armv7 


After confirming the target architecture, complete the installation procedure by performing an 


install: 


$ sudo make install 


The default installation directory is /usr/local/ssl/Release-iphoneos/. 


After installation, delete the openss1-fips-2.0.1/ directory since its no longer needed: 


$ rm -rf 


openssl-fips-1.0.1c/ 


You might encounter issues due to the configuration options. The issues have been cleared in the 
version control system, but the tarballs maybe dated. If so, the issues and the fixes are listed below. 
Recall you have latitude in changing source files because the OpenSSL FIPS Capable Library is 


outside the Cryptographic Module (CM) boundary. 


Issue 


Remedy 


Built-in tools not on path 


Open setenv-ios-11.sh, and change the 
CROSS_COMPILE variable to 
CROSS COMPILE-"SCROSS CHAIN" 


No valid iOS SDK 


Open the setenv-ios-11.sh, and change 
the £or loop to include 6.2, 6.1, and 6.0 


makedepend: warning: 
"armv7" 


cannot open 


makedepend: error: 


Open the Makefile, and change 
MAKEDEPPROG=makedepend to 
MAKEDEPPROG=$ (CC) -M 


Undefined symbols for architecture 
armv7: " ERR load COMP strings" 


Open err all.c, and delete all declarations 
of ERR load COMP strings () 
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OpenSSL Xcode Application 


OpenSSL offers a sample Xcode project to test your installation. The minimal project demonstrates 
linking against the FIPS Capable Library, enabling FIPS Mode, disabling FIPS mode, displaying 
the embedded and calculated fingerprint, and displaying critical values from fips premain.c. 
A screen capture from the device is shown in Illustration 1: OpenSSL FIPS Sample Program. 


The essence of the sample code is shown in the listing below. The code toggles FIPS mode by way 
of FIPS_mode() and FIPS mode set () ; and retrieves error information via ERR_get error(). 
The functions are available from <openss1/crypto.h> and <openss1/err.h> respectively. In 
the case of an error, error values were discussed in Appendix D FIPS API Documentation. 


int mode = FIPS_mode(), ret = 0; 
unsigned long err = 0; 


if(mode == 0) 


{ 
ret = FIPS mode set (1 /*on*/); 
err = ERR get error (); 

} 

else 

{ 
ret = FIPS mode set(0 /*off*/); 
err - ERR get error(); 

} 


if (1 != ret) 
DisplayError("FIPS mode set failed", err); 


After creating an Xcode project, you must add fips premain.c to the project. Copy 

fips premain.c from its location at /usr/1ocal/ssl/Release-iphoneos/lib/ into 
your project's working directory. Since the file is outside the Cryptographic Module (CM) 
boundary, you can check it in to revision control and even modify it if desired (within reason). 
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eoo fips-pi.xcodeproj — [c] fips premain.c 2 
MM ae = lean fips-pi: Today at 8:17 AM "ES I A ma) (ET 
(>) (m) | ro ) í = | Clean fips-pi: Succeeded | Today at E] m E a] | ] 
Run Stop Scheme Breakpoints Project AL - -— Editor View Organizer 
lam TT 04 = » B mi 4 > EA fips-pi> ( fips-pi >) | Supporting Files > [c] fips premain.c > No Selection ja» 


x en iOS SDK 6.0 
v |) fips-pi 
[h] AppDelegate.h 
Im) AppDelegate.m 
[h] ViewController.h 
Im) ViewController.m 
«1 ViewController.xib 
Y (Supporting Files 


fips_assert.h 14 
fips_assert.c 
fips-pi.plist 
fips-pi.pch 

, | InfoPlist.strings 

«| OpenSSL-logo.png 


> [J Icons 
+/08B(S 


B 
Ih] 
le] 
E 
fh] 


* Copyright (c) 2012 The OpenSSL Project. Rights for redistribution 
* and usage in source and binary forms are granted according to the 
* OpenSSL license. 


= --2--------------------- —EEEEEEEEE EE EE EE EES == SEER EE EE SEER 


= */ 


7| #include <stdio.h> 


#include <stdlib.h> 

#include <string.h> 

#if defined( unix) || defined( unix ) || defined(__vxworks) 
defined(. APPLE ) 

include <unistd.h> 

#endif 


|| defined( ANDROID ) || 


4| #ifndef FINGERPRINT  PREMAIN DSO LOAD 


#if defined( GNUC ) && __GNUC__>=2 
void FINGERPRINT premain(void) _ attribute ((constructor)); 
/* Most commonly this results in pointer to premain to be dropped 
* to .ctors segment, which is traversed by GCC crtbegin.o upon 
* program startup. Except on a.out OpenBSD where it results in 
* GLOBAL SISpremain() {premain();} being auto-generated by 
* compiler... But one way or another this is believed to cover 
+ walls GCC targets. */ 


2| #elif defined( MSC VER) 


Illustration 3: fi 


The Xcode Build Settings to compile an OpenSSL dependent program are discussed below. The 
Build Setting should be set on the Project, and not the Target (all targets inherit from the project). 
The sample project has screen captures of the relevant changes under Xcode in the top level 


settings/ directory. 


Build Setting 


Value 


Architectures 
(ARCHS) 


armv7 (remove armv6 and/or armv7s, unless you built 
for the architecture). 


Always Search User Paths 
(ALWAYS SEARCH USER PATHS) 


Yes (due to include «openssl/crypto.h» in non- 
standard location) 


User header Search Paths 
(USER HEADER SEARCH PATHS) 


/usr/local/ssl/Release-iphoneos/include/ 


Other Linker Flags /usr/local/ssl/Release-iphoneos/libcrypto.a (use the 
(OTHER LDFLAGS) fully specified pathname, without -1 or —L) 

Build Setting Value 
Valid Architectures armv7 (remove armv6 and/or armv7s, unless you built 


(VALID ARCHS) 


for the architecture). 


Always Search User Paths 
(ALWAYS SEARCH USER PATHS) 


Yes (due to include «openssl/crypto.h» in non- 
standard location) 


User header Search Paths 
(USER HEADER SEARCH PATHS) 


/usr/local/ssl/Release-iphoneos/include/ 


Other Linker Flags 
(OTHER LDFLAGS) 


/usr/local/ssl/Release-iphoneos/liberypto.a (use the 
fully specified filename, without -1 or —L) 
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The final modification is a Build Phase Script on the Target (not the Project) to embed the 
Module's expected signature using incore_macho. The full command to embed the signature is 
/usr/local/bin/incore macho -exe "SCONFIGURATION BUILD DIR/SEXECUTABLE PATH". 


eoo fips-pi.xcodeproj e 
O) © [erev] (Œ) i emanan (a) 


Run Stop. Scheme Breakpoints — Project. 2 


uja > | FS fips-pi ar 
PROJECT Summary Info Build Settings | Build Phases | f Build Rules 
n fips-pi = 


TARGETS | b Target Dependencies (0 items) 
pa 
| 


Editor View Organizer 


E |> Compile Sources (5 items) 
» Link Binary With Libraries (3 items) 


» Copy Bundle Resources (4 items) 


| w Embed Fingerprint 


Shell | /bin/sh 
1| /usr/local/bin/incore macho —debug -exe "$CONFIGURATION BUILD DIR/SEXECUTABLE PATH" 


Mw Show environment variables in build log 


|.) Run script only when installing 


Add Target Validate Settings Add Build Phase 


Illustration 4: Xcode Build Phase and Incore 


E.3 Windows CE Support 


NOTE: This section is incomplete 


The Microsoft Windows mobile operating systems are among the most challenging platform for the 
FIPS Object Module, due to the wide variation among individual system configurations. 


Representative Build 


These instructions are necessarily only representative of one specific configuration and may require 
substantial modification for specific Windows CE or EC platforms. 


Typically a version of Visual Studio will be used. In this representative example the following 
environment variables are defined in a .BAT file, setenv-wince6. bat: 


@rem 

@rem setenv_wince.cmd 

@rem 

@rem Paths for Visual Studio 2008 on command line (on-64-bit 
host) 
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@call "c:\Program Files\Microsoft Visual Studio 
9.0\VC\"vevarsall.bat 


@set 
@set 
@set 


@set 
ESET 


OSVERSI 


ON=WCE 600 


PLATFORM=MACKEREL 


IARGETCPU-ARMVAI 


WCECOMPAT=C: \wcecompat 
MACKERELSDK=C: \Program Files\Windows CE 
Tools\wce600\Mackerel SDK 


@set PATH=%VSINSTALLDIR%S\Common7\IDE; $VCINSTALLDIR 


%\ce\bin\x86_ 
@set INCLUDE= 


%\ce\include; SINCLUDES 
LIB=SMACKERELSDKS\Lib\ARMV4I; %VCINSTALLDIR 
libNarmv4i; sLIB% 
LIBPATH=SMACKERELSDKS\Lib\ARMV4I; SVCINSTALLDIR 
ib\armv4i;SLIBPATHS 


@set 


%\ce\] 


@set 


%\ce\] 


@set 


@set 


arm; 3VCINSTALLDIR%\bin; SNASMINSTALLDIRS; SPATHS 
MACKERELSDK%\Include\Armv4i; $SVCINSTALLDIR 


oe 


FIPS SHA1 PATH-perl /openssl-fips 
2.0/util/fips standalone shal 


FIPS S 


G-perl /openssl-fips-2.0/util/msincore 


On the Windows build system, invoke a DOS Command Prompt and in that shell enter the 


following: 


X: \>setenv-wince6 


X:\>cl 
Microsoft (R) C/C++ Optimizing Compiler Version 15.00.20720 
for ARM 
Copyright (C) Microsoft Corporation. All rights reserved. 
usage: cl [ option... ] filename... [ /link linkoption... ] 
X:\> 
X:\>ed openssl-fips-2.0 
X:\openssl-fips-2.0>ms\do fips 
X:\openssl-fips-2.0>nmake -f ms\cedll.mak build algvs 

In either case a "Press any key to continue . . . " prompt will be seen. 


At this point the FIPS Object Module and fips algvs utility program have been created. 
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General Considerations 


DLLs present on CE versions prior to 6.0 take away a portion of precious 32MB address space 
from all processes”. This means that unlike "normal" Windows, where DLL load address 
availability is a per-process attribute, it's a per-system attribute for CE pre-6.0. In more practical 
terms the determination of the load address can be dependent on the order in which processes are 
started. In general the static link method is preferred on CE, unless the DLL is ROM-based, and use 
of ce[dll].mak instead of nt[dll].mak. 


Note that the two-step link is not necessary for Windows, as use of the msincore utility after a 
conventional link is sufficient. For the runtime integrity test (fingerprint verification) to succeed a 
binary module, either .exe or .dll, must be loaded at a predefined address or not contain any 
relocations. As there is virtually no control over the load address for CE, fingerprint verification in 
a DLL will fail. The only solution is to statically link the FIPS Object Module into an .exe 
executable and not as a DLL. 


The build for the formally tested Win CE 5 platform used a ROM-based DLL and some flags set in 
Platform Builder. A normal DLL would not work as it ignored the load address and setting /FIXED 
stopped it loading altogether. 


Note the fipslink.pl utility can handle even statically linked applications. 


Note that Windows and Linux cannot be compared in this context, because Linux can generate 
position-independent code which means we avoid any difficulties with base addresses, relocations, 
etc. For Windows a consistent load address is needed for the DLL. If that DLL isn't ROM-based 
then things like the load order can result in different addresses which will result in an invalid 
signature. 


So one (messy) solution is to set up platform builder to get that consistent load address: as long as 
it doesn't change it doesn't matter what it is. The process viewer tool can be used to check the load 
address. Then once a fixed address has been established it can be used to build the FIPS capable 
OpenSSL to embed the signature; this is the - -with-baseaddr-«address» option to 
Configure. 


“CE DLLs steal memory from all processes, so if only one application needs to operate in validated mode then a 
statically linked module is preferable. 
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Appendix F Restrictions on the Export of Cryptography 


Government restrictions and regulations on the use, acquisition, and distribution of cryptographic 
products are a matter of concern for some potential users. 


F.1 Open Source Software 


In the United States the current export regulations appear to more or less leave open source 
software in source code format alone, except for a reporting requirement to the Bureau of Industry 
and Security (BIS) of the U.S. Department of Commerce; see 


http://bxa.doc.gov/Encryption/pubavailencsourcecodenofify.html. 


When in doubt consultation with legal experts would be appropriate. An example of an E-mail 
message sent to comply with this reporting requirement is: 


To: crypt@bis.doc.gov, enc@nsa.gov, web_site@bis.doc.gov 
Subject: TSU NOTIFICATION 


SUBMISSION TYPE: TSU 


SUBMITTED BY: Steve Marquess 

SUBMITTED FOR: OpenSSL Software Foundation, Inc. 
POINT OF CONTACT: Steve Marquess 

PHONE and/or FAX: 877-673-6775 

ANUFACTURER: N/A 

PRODUCT NAME/MODEL #: OpenSSL 

ECCN: 5D002 


NOTIFICATION: http://cvs.openssl.org/dir 


Employee(s), subcontractor(s), and/or agent(s) of the OpenSSL Software 
Foundation, Inc. (OSF) are participating in the development of the freely 
available open source OpenSSL product by providing feedback on new 
releases, by requesting new features, by correspondenc ither to the 
developer and user mailing lists or directly with the product developers, 
and by subcontracting software development services to one or more of 

the OpenSSL developers. This correspondence may include suggested 

source code fragments or patches. All versions of any such contributions 
incorporated, or software implemented, in any of the OpenSSL software 
will be publicly accessible at http://cvs.openssl.org/dir. 


Steve Marquess 

OpenSSL Software Foundation, Inc. 
1829 Mount Ephraim Road 
Adamstown, MD 21710 

USA 

+1 877-673-6775 
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marquess@marquess@openssl „COM 


No response was received (or expected). 


Other links of interest: 


http://bxa.doc.gov/Encryption/ChecklistInstr.htm 
F.2 “Export Jobs, Not Crypto” 


For software exported in binary form the situation is far less certain. As incredible and 
unbelievably opposed to common sense as it seems, current U.S. export controls appear to restrict 
the export from the U.S. of software products that use the OpenSSL product, even if OpensSSL is 
used exclusively for all cryptographic functionality. 


From what has been relayed from several vendors affected by these export restrictions, export 
approval for software utilizing OpenSSL is contingent on a number of factors including the type of 
linking (static build-time linking or dynamic run-time linking). Static linking is more desirable, 
apparently something to do with the concept of an “open cryptographic interface”. Evidently a 
product where the end user can easily substitute a new cryptographic library (a newer version of 
OpenSSL, say) is not permissible. 


Needless to say the written regulations and expert commentary are varied, so advice of legal 
counsel is recommended. The only other safe course of action would be to pay non-U.S. citizens to 
develop the cryptographic software overseas and import it into the U.S., as imports are not 
restricted. Foreigners who benefit financially from this situation refer to the U.S. “export jobs, not 


crypto” policy. 


Links of interest: 


http://www.axsmith.com/Encryption_Law.htm 
http: //library.findlaw.com/2000/Jan/1/128443 html 
http: //cryptome.org/bxa-bernstein.htm 
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APPENDIX G Security Policy Errata 


The formal Security Policy 
(http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1747.pdf is a controlled 
document and so, as with the validated software proper, cannot readily be changed. This section 
lists known errors in that document. 


Table 2: The operating system for platform 9 is listed as "Android 2.2". That device was the 
Motorola Xoom running Android 3.0, the earliest version of Android that device shipped 
with. During the period the validation was in process that version of Android on that device 
was superseded by Android 4.0 which was tested as platform 39, so platform 9 is of 
academic interest only (note platform essentially 9 duplicates platform 2). The error was 
reported to the test lab even prior to the formal validation award, but since correction of 
errors in completed validations is difficult we elected not to press the issue. 
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Appendix H DTR Analysis 
[TBD] 
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Appendix! API Entry Points by Source File 


The API entry points in the Module are listed here, organized by source file. 


FIPS 140-2 requires that logical interfaces have to be identified as one of "data input", "data 
output", "control input", or "status output". Functions with multiple arguments and the C language 
argument passing mechanism do not naturally match these categories, especially where pointers to 
structures are used. This table designates each function as primarily serving one of the four 
purposes, with the individual arguments also designated as input, output, or both. 


The function names are in bold. Input arguments are highlighted in Grey and listed with a right 
pointing arrow (->). Output arguments are listed with a left pointing arrow (<-). Pointer arguments 
referencing structures containing both input and output data elements are listed with a double arrow 
(<->). The function return value is denoted in the list of arguments as "Return". 


Note that many of these Module API functions calls are rarely 1f ever referenced directly by 
applications, instead they are referenced from the separate OpenSSL product by a non- 
cryptographic abstraction layer such as the EVP interface (see Reference 11). Some external 
symbols defined in the Module but not intended for reference by calling applications are omitted. 
Also note that the API as documented below may vary slightly by platform due to the use of 
assembly language optimizations. 


Some general notes: 


The POST code is contained in the ./fips/ subdirectory, beginning with the 
FIPS module mode set () function in .//ips/fips.c and leading directly functions defined in 


/fips/fips post.c. 


The best way to trace each of the algorithm implementations is from the respective algorithm test 
drivers, as they start with the CAVS test vector request file data and make the appropriate API calls 
to perform the algorithm processing. Those are found in the ./fips/XXX/ directories, for "XXX" the 
algorithm, and are also symlinked from the ./test/ subdirectory: 


test/fips aesavs.c -> ../fips/aes/fips aesavs.c 
test/fips cmactest.c -> ../fips/cmac/fips_cmactest.c 
test/fips desmovs.c -> ../fips/des/fips desmovs.c 
test/fips dhvs.c -> ../fips/dh/fips dhvs.c 

test/fips drbgvs.c -> ../fips/rand/fips_drbgvs.c 
test/fips dsatest.c -> ../fips/dsa/fips_dsatest.c 
test/fips dssvs.c -> ../fips/dsa/fips dssvs.c 
test/fips ecdhvs.c -> ../fips/ecdh/fips ecdhvs.c 
test/fips ecdsavs.c -> ../fips/ecdsa/fips ecdsavs.c 
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test/fips gcmtest.c -> ./fips/aes/fips gcmtest.c 
test/fips hmactest.c -> ../fips/hmac/fips hmactest.c 
test/fips randtest.c -> ../fips/rand/fips randtest.c 
test/fips rngvs.c -> ./fips/rand/fips rngvs.c 
test/fips rsagtest.c -> ../fips/rsa/fips rsagtest.c 
test/fips rsastest.c -> ../fips/rsa/fips_rsastest.c 
test/fips rsavtest.c -> ../fips/rsa/fips rsavtest.c 
test/fips shatest.c -> ../fips/sha/fips_shatest.c 


Note the algorithm test drivers themselves are not part of the FIPS module. 
Symbol renaming: Some symbol names as defined in the source code are dynamically redefined at 
build time. This API documentation shows both the original (source code) and build time (object 


code) symbol names, for instance: 


FIPS bn bn2bin (renames BN bn2bin) in file 
./crypto/bn/bn lib. [olc] 


which indicates that the FIPS bn bn2bin() function as seen in the compiled code 
(./crypto/bn/bn_lib.o) is found in the source code as function BN bn2bin() in source file 
./crypto/bn/bn_lib.c. 

Some functions are not renamed, for instance: 


FIPS module mode set in file ./fips/fips.[olc] 


indicates that FIPS_ module mode set() is defined in ./fips/fips.c and ./fips/fips.o with the same 
symbol name. Likewise, 


FIPS add lock (reimplements CRYPTO add lock) in file 
./fips/utl/fips lck.[o|c] 


indicates that FIPS add lock () is defined by that name in both ./fips/utl/fips lck.o and 
/fips/utl/fips lck.c; the "reimplements" notation refers to the redefinition of this FIPS module 
specific function to replace a similar known function from the original OpenSSL distribution from 
which the FIPS module was derived. 


This list was produced by the api list.p1l tool in the ./fips/tools/ subdirectory of the source 
code distribution, using supporting files also in that directory: 


api fns.pm a perl module that for api list.pl 
declarations.dat a file of information about public fips symbols 
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This utility attempts to "direction of use" for each function parameter, i.e. whether that parameter is 
referenced as input, as output, or both. That determination is far from clear in some cases, as for 
some types of parameters there is no clear answer -- consider for instance a pointer to a structure 
containing a callback to a function that is only called as an exception. In any event that information 
1s stored in the file declarations.dat and can be manually corrected by replacing the value 
for the key 'direction' where the value contains a question mark. Those values can be changed as 
appropriate, to one of: 


<- output 
=> input 
<-> both 


and the manually changed values will be preserved in the declarations.dat file. The 
api_list.pl utility has no command line options and is invoked from the root of the source 
code work area: 


perl fips/tools/api_list.pl > <outfile> 


The HTML formatted contents of the output file can be lightly edited for inclusion in documents 
such as this one. 


This following list shows the functions in alphabetical order by the runtime symbol name. 


FIPS add error data (reimplements ERR add error data) in file /fips/utV/fips err.[o|c] 


void FIPS add error data(int num, …) 
-> num 
= 


FIPS add lock (reimplements CRYPTO add lock) in file ./fips/utl/fips_Ick.[o|c] 


int FIPS_add_lock(int *pointer, int amount, int type, const char *file, int line) 


<- pointer 
-> amount 
d type 

> file 

> line 

<- Return 
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FIPS bn bin2bn (renames BN bin2bn) in file ./crypto/bn/bn lib.[o|c] 


BIGNUM *FIPS bn bin2bn(const unsigned char *s, int len, BIGNUM *ret) 
E» S 


> len 
<-> ret 
<- Return 


FIPS bn bn2bin (renames BN bn2bin) in file ./crypto/bn/bn_lib.[o|c] 


int FIPS_bn_bn2bin(const BIGNUM *a, unsigned char *to) 


E» a 
«- to 
<- Return 


FIPS bn clear (renames BN clear) in file ./crypto/bn/bn_lib.[o|c] 


void FIPS bn clear(BIGNUM *a) 
<-> a 


FIPS bn clear free (renames BN clear free) in file ./crypto/bn/bn_lib.[o|c] 


void FIPS bn clear free(BIGNUM *a) 
<-> a 


FIPS bn free (renames BN free) in file ./crypto/bn/bn_lib.[o|c] 


void FIPS bn free(BIGNUM *a) 
<-> a 


FIPS bn generate prime ex (renames BN generate prime ex) in file ./crypto/bn/bn_prime.[o|c] 


int FIPS_bn_generate_prime_ex(BIGNUM *ret, int bits, int safe, const BIGNUM *add, const 
BIGNUM “rem, BN GENCB *cb) 


<-> ret 

> bits 
-> safe 
-> add 
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-> rem 
<-> cb 
<- Return 


FIPS bn get word (renames BN get word) in file ./crypto/bn/bn lib.[o|c] 


BN_ULONG FIPS_bn_get_word(const BIGNUM *a) 
=> a 
<- Return 


FIPS bn is bit set (renames BN is bit set) in file /crypto/bn/bn lib.[o|c] 


int FIPS bn is bit set(const BIGNUM *a, int n) 


> a 
> n 
< Return 


FIPS bn is prime ex (renames BN is prime ex) in file ./crypto/bn/bn_prime.[o|c] 


int FIPS bn is prime ex(const BIGNUM *p, int nchecks, BN CTX *ctx, BN GENCB *cb) 


a p 

-> nchecks 
<- ctx 

<-> cb 

< Return 


FIPS bn is prime fasttest ex (renames BN is prime fasttest ex) in file ./crypto/bn/bn_prime.[o| 
c] 


int FIPS bn is prime fasttest ex(const BIGNUM *p, int nchecks, BN CTX *ctx, int 
do trial division, BN GENCB *cb) 


> p 

-> nchecks 

<- ctx 

-> do trial division 
<-> cb g 

<- Return 
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FIPS bn new (renames BN new) in file ./crypto/bn/bn lib.[o|c] 


BIGNUM *FIPS bn new() 
<- Return 


FIPS bn num bits (renames BN num bits) in file ./crypto/bn/bn_lib.[o|c] 


int FIPS bn num bits(const BIGNUM *a) 
> a 
<- Return 


FIPS bn num bits word (renames BN num bits word) in file ./crypto/bn/bn lib.[o|c] 


int FIPS bn num bits word(BN_ULONG l) 
-> 1 
<- Return 


FIPS bn pseudo rand (renames BN pseudo rand) in file /crypto/bn/bn rand.[o|c] 


int FIPS bn pseudo rand(BIGNUM *rnd, int bits, int top, int bottom) 


<-> rd 
> bits 
-> top 
-> bottom 
<- Return 


FIPS bn pseudo rand range (renames BN pseudo rand range) in file /crypto/bn/bn rand.[o|c] 


int FIPS bn pseudo rand range(BIGNUM “mnd, const BIGNUM *range) 
<-> md 

-^ range 

<- Return 


FIPS bn rand (renames BN rand) in file /crypto/bn/bn rand.[o|c] 
int FIPS_bn_rand(BIGNUM *rnd, int bits, int top, int bottom) 


<-> rnd 
> bits 
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> top 
> bottom 
<- Return 


FIPS bn rand range (renames BN rand range) in file /crypto/bn/bn rand.[o|c] 


int FIPS_bn_rand_range(BIGNUM *rnd, const BIGNUM *range) 


<-> rnd 
-> range 
<- Return 


FIPS bn set bit (renames BN set bit) in file ./crypto/bn/bn lib.[o|c] 


int FIPS bn set bit(BIGNUM *a, int n) 


<-> a 
E» n 
<- Return 


FIPS bn x931 derive prime ex (renames BN_X931 derive prime ex) in file 
./crypto/bn/bn_x931p.[o|c] 


int FIPS bn x931 derive prime ex(BIGNUM *p, BIGNUM *pl, BIGNUM *p2, const 
BIGNUM *Xp, const BIGNUM *Xpl, const BIGNUM *Xp2, const BIGNUM *e, BN CTX *ctx, 
BN GENCB *cb) 


<-> p 

<> pl 

<> p2 

-> Xp 

-> Xpl 

> Xp2 
ds e 

<- ctx 
<> cb 

«- Return 


FIPS bn x931 generate prime ex (renames BN X931 generate prime ex) in file 
Jerypto/bn/bn x931p.[olc] 


int FIPS bn x931 generate prime ex(BIGNUM *p, BIGNUM *pl, BIGNUM *p2, BIGNUM 


Page 171 of 225 


User Guide - OpenSSL FIPS Object Module v2.0 


*Xpl, BIGNUM *Xp2, const BIGNUM *Xp, const BIGNUM *e, BN CTX *ctx, BN GENCB 
*cb) 


<-> p 

<> pl 

<-> p2 

<> Xpl 
<-> Xp2 
=>: Xp 

<> e 

<- ctx 
<-> cb 

<- Return 


FIPS bn x931 generate xpq (renames BN_X931_generate_Xpq) in file ./crypto/bn/bn_x931p.[o| 
c] 


int FIPS bn x931 generate xpq(BIGNUM *Xp, BIGNUM *Xq, int nbits, BN CTX *ctx) 


<-> Xp 
<-> Xq 

-> nbits 
<- ctx 

<- Return 


FIPS check incore fingerprint in file ./fips/fips.[o|c] 


int FIPS check incore fingerprint() 
<- Return 


FIPS cipher (reimplements EVP Cipher) in file /fips/utl/fips enc.[o|c] 


_ owur int FIPS cipher(EVP CIPHER CTX *c, unsigned char *out, const unsigned char *in, 
unsigned int inl) 


<- c 

<- out 

> in 

> inl 

<- Return 
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FIPS cipher ctx cleanup (reimplements EVP_CIPHER_CTX_cleanup) in file ./fips/utl/fips_enc. 
[ole] 


int FIPS cipher ctx cleanup(EVP CIPHER CTX *a) 
<- a 
<- Return 


FIPS cipher ctx copy (reimplements EVP CIPHER CTX copy) in file /fips/utl/fips_enc.[olc] 


int FIPS cipher ctx copy(EVP CIPHER CTX “out, const EVP CIPHER CTX *in) 
<- out 

-> in 

<- Return 


FIPS _ cipher ctx ctrl (reimplements EVP_CIPHER CTX ctrl) in file ./fips/utl/fips_enc.[o|c] 


int FIPS cipher ctx ctrl(EVP CIPHER CTX “etx, int type, int arg, void *ptr) 
<- ctx 


za type 
-> arg 
<-> ptr 

<- Return 


FIPS cipher ctx free (reimplements EVP CIPHER CTX free) in file /fips/utl/fips_enc.[olc] 


void FIPS cipher ctx free(EVP CIPHER CTX *a) 
<- a 


FIPS cipher ctx init (reimplements EVP_CIPHER CTX init) in file ./fips/utl/fips_enc.[o|c] 


void FIPS cipher ctx init(EVP CIPHER CTX *a) 
<- a 


FIPS cipher ctx new (reimplements EVP_CIPHER_CTX_new) in file ./fips/utl/fips_enc.[o|c] 


EVP CIPHER CTX *FIPS cipher ctx new() 
<- Return 
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FIPS cipher ctx set key length (reimplements EVP CIPHER CTX set key length) in file 
Jfips/utl/fips_enc.[olc] 


int FIPS cipher ctx set key length(EVP CIPHER CTX *x, int keylen) 
< X 

->  keylen 

<- Return 


FIPS cipherinit (reimplements EVP Cipherlnit) in file ./fips/utl/fips_enc.[o|c] 


_ owur int FIPS cipherinit(EVP CIPHER CTX *ctx, const EVP_CIPHER *cipher, const 
unsigned char *key, const unsigned char *tv, int enc) 


<- ctx 

-> cipher 
-> key 

-> iv 

-> enc 

<- Return 


FIPS cmac ctx cleanup (renames CMAC CTX cleanup) in file ./crypto/cmac/cmac.[o|c] 


void FIPS cmac ctx cleanup(CMAC CTX *ctx) 
<= ctx 


FIPS cmac ctx copy (renames CMAC CTX copy) in file ./crypto/cmac/cmac.[o|c] 


int FIPS_cmac_ctx_copy(CMAC_CTX *out, const CMAC CTX *in) 
<= out 

> in 

<- Return 


FIPS cmac ctx free (renames CMAC CTX free) in file ./crypto/cmac/cmac.[o|c] 


void FIPS cmac ctx free(CMAC CTX *ctx) 
< ctx 


FIPS cmac ctx getO cipher ctx (renames CMAC CTX get) cipher ctx) in file 
./crypto/emac/cmac.[o|c] 
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EVP CIPHER CTX *FIPS_cmac_ctx_get0_cipher_ctx(CMAC_ CTX *ctx) 
<- ctx 
<- Return 


FIPS_cmac_ctx_new (renames CMAC CTX new) in file ./crypto/cmac/cmac.[olc] 


CMAC CTX *FIPS cmac ctx new() 
<- Return 


FIPS cmac final (renames CMAC Final) in file /crypto/cmac/cmac.[olc] 


int FIPS cmac final(CMAC CTX *ctx, unsigned char “out, size_t *poutlen) 
<= ctx 


<- out 
<-  poutlen 
<- Return 


FIPS cmac init (renames CMAC Init) in file ./crypto/emac/cmac.[o|c] 


int FIPS cmac init(CMAC CTX *ctx, const void *key, size t keylen, const EVP CIPHER 
*cipher, ENGINE *impl) 


< ctx 

> key 

->  keylen 
-> cipher 
<-> impl 
<- Return 


FIPS cmac resume (renames CMAC resume) in file ./crypto/cmac/cmac.[o|c] 


int FIPS cmac resume(CMAC CTX *ctx) 
<= ctx 
<- Return 


FIPS cmac update (renames CMAC Update) in file /crypto/cmac/cmac.[o|c] 


int FIPS cmac update(CMAC CTX *ctx, const void “data, size t dlen) 
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<- ctx 

-> data 
-> dlen 
<- Return 


FIPS erypto get id callback (renames CRYPTO get id callback) in file /crypto/thr id.[o|c] 


unsigned long (*FIPS crypto get id callback())(void) 
<- Return 


FIPS crypto set id callback (renames CRYPTO set id callback) in file ./crypto/thr_id.[o|c] 


void FIPS crypto set id callback(unsigned long (*func)(void)) 
<-> func 


FIPS crypto thread id (renames CRYPTO thread id) in file ./crypto/thr_id.[o|c] 


unsigned long FIPS crypto thread id() 
<- Return 


FIPS crypto threadid get callback (renames CRYPTO THREADID get callback) in file 
/erypto/thr_id.[o|c] 


void (*FIPS crypto_threadid_get_callback())(CRYPTO THREADID *) 
<- Return 


FIPS crypto threadid hash (renames CRYPTO THREADID hash) in file ./crypto/thr_id.[o|c] 


unsigned long FIPS crypto threadid hash(const CRYPTO THREADID *id) 
> id 
<- Return 


FIPS crypto threadid set callback (renames CRYPTO THREADID set callback) in file 
Jerypto/thr_id.[olc] 


int FIPS crypto threadid set callback(void (*threadid fune)(CRYPTO THREADID *)) 
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<->  threadid func 
<- Return 


FIPS erypto threadid set numeric (renames CRYPTO THREADID set numeric) in file 
/erypto/thr_id.[o|c] 


void FIPS crypto threadid set numeric(CRYPTO THREADID “id, unsigned long val) 
<> id 
> val 


FIPS crypto threadid set pointer (renames CRYPTO THREADID set pointer) in file 
Jerypto/thr id.[o|c] 


void FIPS crypto threadid set pointer(CRYPTO THREADID *id, void *ptr) 
<> id 
<-> ptr 


FIPS des check key parity (renames DES check key parity) in file ./crypto/des/set_key.[o|c] 


int FIPS des check key parity(const DES cblock *key) 
-> key 
<- Return 


FIPS dh check (renames DH check) in file /crypto/dh/dh check.[o|c] 


int FIPS_dh_check(const DH *dh, int *codes) 


> dh 
<- codes 
<- Return 


FIPS dh check pub key (renames DH check pub key) in file /crypto/dh/dh check.[o|c] 


int FIPS dh check pub key(const DH *dh, const BIGNUM *pub_key, int *codes) 
-> dh 


-> | pub key 
<- codes 
<- Return 
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FIPS dh compute key (renames DH compute key) in file /crypto/dh/dh key.[o|c] 


int FIPS dh compute key(unsigned char *key, const BIGNUM *pub key, DH *dh) 


< key 

-> | pub key 
<> dh 

<- Return 


FIPS dh compute key padded (renames DH compute key padded) in file /crypto/dh/dh key.[o| 
c] 


int FIPS dh compute key padded(unsigned char *key, const BIGNUM *pub key, DH *dh) 
<- key 


-> pub key 
<-> dh 
<- Return 


FIPS dh free in file ./fips/dh/fips dh lib.[olc] 


void FIPS_dh_free(DH *dh) 
<> dh 


FIPS dh generate key (renames DH generate key) in file ./crypto/dh/dh key.[olc] 


int FIPS_dh_generate_key(DH *dh) 
<> dh 
<- Return 


FIPS dh generate parameters ex (renames DH generate parameters ex) in file 
/crypto/dh/dh_gen.[o|c] 


int FIPS dh generate parameters ex(DH *dh, int prime len, int generator, BN GENCB *cb) 
<> dh 

-^ prime len 

-> generator 

<-> cb 

<- Return 
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FIPS dh new in file ./fips/dh/fips dh lib.[o|c] 


DH * FIPS dh new() 
«- Return 


FIPS dh openssl (renames DH OpenSSL) in file ./crypto/dh/dh_key.[o|c] 


const DH METHOD *FIPS dh openssl() 
<- Return 


FIPS digest (reimplements EVP Digest) in file /fips/utl/fips_md.[olc] 


. owur int FIPS digest(const void *data, size t count, unsigned char *md, unsigned int “size, 
const EVP_MD *type, ENGINE *impl) 


-> data 
-> count 
<- md 

<- size 

ee type 
<-> impl 
<- Return 


FIPS digestfinal (reimplements EVP_DigestFinal_ex) in file /fips/utl/fips md.[o|c] 


. owur int FIPS digestfinal(EVP MD CTX *ctx, unsigned char *md, unsigned int *s) 
< ctx 


<- md 
<- s 
<- Return 


FIPS digestinit (reimplements EVP_DigestInit) in file /fips/utl/fips md.[o|c] 


. owur int FIPS digestinit(EVP MD CTX *etx, const EVP MD *type) 
<- ctx 


-> type 
<- Return 
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FIPS digestupdate (reimplements EVP_DigestUpdate) in file ./fips/utl/fips_md.[o|c] 


. owur int FIPS digestupdate(EVP MD CTX *ctx, const void *d, size t ent) 
<= ctx 


-> d 
-> cnt 
<- Return 


FIPS drbg free in file /fips/rand/fips drbg lib.[o|c] 


void FIPS drbg free(DRBG CTX *dctx) 
<- dctx 


FIPS drbg generate in file /fips/rand/fips drbg lib.[o|c] 


int FIPS drbg generate(DRBG CTX *detx, unsigned char *out, size t outlen, int 
prediction resistance, const unsigned char *adin, size t adinlen) 
<- dctx 


<- out 

-> outlen 

-> prediction resistance 
-> adin 

-> adinlen 

<- Return 


FIPS drbg get app data in file /fips/rand/fips drbg lib.[o|c] 


void *FIPS drbg get app data(DRBG CTX *ctx) 
<= ctx 
<- Return 


FIPS drbg get blocklength in file /fips/rand/fips drbg lib.[olc] 


size t FIPS drbg get blocklength(DRBG CTX *dctx) 
<- dctx 
<- Return 
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FIPS drbg get strength in file /fips/rand/fips drbg lib.[o|c] 


int FIPS drbg get strength(DRBG CTX *dctx) 
<-  detx 
<- Return 


FIPS drbg health check in file /fips/rand/fips drbg selftest.[o|c] 


int FIPS drbg health check(DRBG CTX *dctx) 
<- detx 
<- Return 


FIPS drbg init in file ./fips/rand/fips drbg lib.[o|c] 


int FIPS drbg init(DRBG CTX *dctx, int type, unsigned int flags) 
<-  detx 


-> type 
-> flags 
<- Return 


FIPS drbg instantiate in file /fips/rand/fips drbg lib.[o|c] 


int FIPS drbg instantiate(DRBG CTX *dctx, const unsigned char *pers, size t perslen) 
<- dctx 


-> pers 
-^ J perslen 
<- Return 


FIPS drbg method in file /fips/rand/fips drbg rand.[o|c] 


const RAND METHOD *FIPS drbg method() 
<- Return 


FIPS drbg new in file /fips/rand/fips drbg lib.[o|c] 


DRBG_CTX *FIPS_drbg_new(int type, unsigned int flags) 
-> type 
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> flags 
< Return 


FIPS drbg reseed in file /fips/rand/fips drbg lib.[o|c] 


int FIPS drbg reseed(DRBG CTX *detx, const unsigned char *adin, size t adinlen) 
<- detx 


-> adin 
-> adinlen 
<- Return 


FIPS drbg set app data in file ./fips/rand/fips drbg lib.[o|c] 


void FIPS drbg set app data(DRBG CTX *ctx, void *app data) 
< ctx 
<-> app data 


FIPS drbg set callbacks in file /fips/rand/fips drbg lib.[o|c] 


int FIPS drbg set callbacks(DRBG CTX *dctx, size t (*get entropy(DRBG CTX *ctx, 
unsigned char **pout, int entropy, size t min len, size t max len), void (*cleanup entropy) 
(DRBG CTX *ctx, unsigned char “out, size t olen), size t entropy blocklen, size t (*get nonce) 
(DRBG CTX *ctx, unsigned char **pout, int entropy, size t min len, size t max len), void 
(*eleanup nonce)(DRBG CTX *ctx, unsigned char *out, size t olen)) 


<-  detx 

<- get_entropy 

<- cleanup entropy 
> entropy_blocklen 
x get nonce 

<- J cleanup nonce 
<- Return 


FIPS drbg set check interval in file /fips/rand/fips drbg lib.[olc] 


void FIPS drbg set check interval(DRBG CTX *dctx, int interval) 
<-  detx 
-> interval 
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FIPS drbg set rand callbacks in file /fips/rand/fips drbg lib.[o|c] 


int FIPS drbg set rand callbacks(DRBG CTX *dctx, size t (*get adin(DRBG CTX *ctx, 
unsigned char **pout), void (*cleanup adinDRBG CTX *ctx, unsigned char *out, size t olen), 
int (“rand seed cb(DRBG CTX *ctx, const void *buf, int num), int (“rand add cb(DRBG CTX 
*ctx, const void *buf, int num, double entropy)) 


<-  detx 
<- get adin 
<- cleanup adin 


-> rand seed cb 
-> rand add cb 
<- Return 


FIPS drbg set reseed interval in file /fips/rand/fips drbg lib.[o|c] 


void FIPS drbg set reseed interval(DRBG CTX *dctx, int interval) 
<- dctx 
-> interval 


FIPS drbg stick in file ./fips/rand/fips drbg lib.[o|c] 


void FIPS drbg stick(int onoff) 
->  onoff 


FIPS drbg uninstantiate in file /fips/rand/fips drbg lib.[o|c] 


int FIPS drbg uninstantiate(DRBG CTX *dctx) 
<-  detx 
<- Return 


FIPS dsa free in file /fips/dsa/fips dsa lib.[o|c] 


void FIPS dsa free(DSA *r) 
<-> Tr 


FIPS dsa generate key (renames DSA generate key) in file ./crypto/dsa/dsa_key.[o|c] 


int FIPS dsa generate key(DSA *a) 
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<-> a 
< Return 


FIPS dsa generate parameters ex (renames DSA generate parameters ex) in file 
/crypto/dsa/dsa_gen.[o|c] 


int FIPS dsa generate parameters ex(DSA *dsa, int bits, const unsigned char “seed, int 
seed len, int “counter ret, unsigned long *h ret, BN GENCB *cb) 


<-> dsa 

-> bits 

-> seed 

-> seed len 
<- counter ret 
<> h ret 

<-> cb 

< Return 


FIPS dsa new in file ./fips/dsa/fips_dsa_lib.[o|c] 


DSA * FIPS_dsa_new() 
<- Return 


FIPS dsa openssl (renames DSA OpenSSL) in file ./crypto/dsa/dsa_ossl.[o|c] 


const DSA METHOD *FIPS dsa openssl() 
<- Return 


FIPS _ dsa sig free (reimplements DSA SIG free) in file /fips/dsa/fips dsa lib.[olc] 


void FIPS dsa sig free(DSA SIG *a) 
<-> a 


FIPS dsa sig new (reimplements DSA SIG new) in file /fips/dsa/fips dsa lib.[o|c] 


DSA SIG * FIPS dsa sig new() 
<- Return 
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FIPS dsa sign in file ./fips/dsa/fips_dsa sign.[olc] 


DSA SIG * FIPS dsa sign(DSA *dsa, const unsigned char *msg, size t msglen, const EVP MD 


*mhash) 
<-> dsa 
-^ msg 


->  msglen 
> mhash 
<- Return 


FIPS dsa sign ctx in file /fips/dsa/fips dsa sign.[o|c] 


DSA SIG * FIPS dsa sign ctx(DSA *dsa, EVP MD CTX *ctx) 


<> dsa 
<- ctx 
<- Return 


FIPS dsa sign digest in file /fips/dsa/fips dsa sign.[o|c] 


DSA SIG * FIPS dsa sign digest(DSA *dsa, const unsigned char *dig, int dlen) 
<-> dsa 


> dig 
> dlen 
<- Return 


FIPS dsa verify in file /fips/dsa/fips dsa sign.[o|c] 


int FIPS dsa verify(DSA *dsa, const unsigned char *msg, size t msglen, const EVP MD 
*mhash, DSA SIG *s) 

<-> dsa 

-^ msg 

->  msglen 

-> mhash 

<-> S 

<- Return 


FIPS dsa verify ctx in file ./fips/dsa/fips_dsa_sign.[o|c] 


int FIPS dsa verify ctx(DSA *dsa, EVP MD CTX *ctx, DSA SIG *s) 
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<-> dsa 

<- ctx 
<-> S 

<- Return 


FIPS dsa verify digest in file ./fips/dsa/fips_dsa sign.[o|c] 


int FIPS_dsa_verify_digest(DSA *dsa, const unsigned char *dig, int dlen, DSA_SIG *s) 
<-> dsa 


> dig 

> dlen 
<-> S 

<- Return 


FIPS ec get builtin curves (renames EC get builtin curves) in file ./crypto/ec/ec_curve.[olc] 


size t FIPS ec get builtin curves(EC builtin curve *r, size t nitems) 


<-> r 
-> nitems 
<- Return 


FIPS ec group clear free (renames EC GROUP clear free) in file ./crypto/ec/ec lib.[o|c] 


void FIPS ec group clear free(EC GROUP *group) 
<-> group 


FIPS ec group get) generator (renames EC GROUP get0 generator) in file /crypto/ec/ec lib.[o| 
c] 


const EC POINT *FIPS ec group get) generator(const EC GROUP *group) 
-^ group 
<- Return 


FIPS ec group get) seed (renames EC GROUP get) seed) in file /crypto/ec/ec lib.[o|c] 


unsigned char *FIPS ec group get) seed(const EC GROUP *x) 
X. X 
<- Return 
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FIPS ec group get asnl flag (renames EC GROUP get asnl flag) in file ./crypto/ec/ec_lib.[o|c] 


int FIPS ec group get asnl_flag(const EC GROUP *group) 
-> group 
<- Return 


FIPS ec group get cofactor (renames EC GROUP get cofactor) in file ./crypto/ec/ec_lib.[o|c] 


int FIPS ec group get cofactor(const EC GROUP *group, BIGNUM “cofactor, BN CTX *ctx) 


-> group 
<-> cofactor 
<- ctx 

<- Return 


FIPS ec group get curve gf2m (renames EC GROUP get curve GF2m) in file 
Jerypto/ec/ec lib.[o|c] 


int FIPS ec group get curve gf2m(const EC GROUP *group, BIGNUM *p, BIGNUM *a, 
BIGNUM *b, BN CTX *ctx) 


-> group 
<-> p 

<-> a 

<-> b 

<- ctx 

<- Return 


FIPS ec group get curve gfp (renames EC GROUP get curve GFp) in file ./crypto/ec/ec_lib.[o| 
c] 


int FIPS ec group get curve gfp(const EC GROUP *group, BIGNUM *p, BIGNUM *a, 
BIGNUM *b, BN CTX *ctx) 


-> group 
<-> p 

<-> a 

<-> b 

<- ctx 

<- Return 
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FIPS ec group get curve name (renames EC GROUP get curve name) in file 
./crypto/ec/ec_lib.[o|c] 


int FIPS ec group get curve name(const EC GROUP *group) 
-> group 
<- Return 


FIPS ec group get degree (renames EC GROUP get degree) in file /crypto/ec/ec lib.[o|c] 


int FIPS ec group get degree(const EC GROUP *group) 
-> group 
<- Return 


FIPS ec group get order (renames EC GROUP get order) in file /crypto/ec/ec lib.[o|c] 


int FIPS ec group get order(const EC GROUP *group, BIGNUM “order, BN CTX *ctx) 


-> group 
<-> order 
<- ctx 

<- Return 


FIPS ec group method of (renames EC GROUP method of) in file ./crypto/ec/ec_lib.[o|c] 


const EC METHOD *FIPS ec group method of(const EC GROUP *group) 
-> group 
<- Return 


FIPS ec group new (renames EC GROUP new) in file /crypto/ec/ec lib.[o|c] 


EC GROUP *FIPS_ec_group_new(const EC METHOD *meth) 
-> meth 
<- Return 


FIPS ec group new by curve name (renames EC GROUP new by curve name) in file 
./crypto/ec/ec_curve.[o|c] 


EC GROUP *FIPS_ec_group_new_by_curve_name(int nid) 
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> nid 
<- Return 


FIPS ec group new curve gf2m (renames EC GROUP new curve GF2m) in file 
./crypto/ec/ec_cvt.[o|c] 


EC GROUP *FIPS ec group new curve gf2m(const BIGNUM *p, const BIGNUM *a, const 
BIGNUM *b, BN CTX *ctx) 


=> p 

E» a 

-> b 

<- ctx 

<- Return 


FIPS ec group new curve gfp (renames EC GROUP new curve GFp) in file ./crypto/ec/ec_cvt. 
[ole] 


EC GROUP *FIPS ec group new curve gfp(const BIGNUM *p, const BIGNUM *a, const 
BIGNUM *b, BN_CTX *ctx) 


> p 

c a 

-> b 

<- ctx 

<- Return 


FIPS ec group precompute mult (renames EC GROUP precompute mult) in file 
./crypto/ec/ec_lib.[o|c] 


int FIPS ec group precompute mult(EC GROUP *group, BN CTX *ctx) 
<-> group 

< ctx 

<- Return 


FIPS ec group set asnl flag (renames EC GROUP set_asn1_flag) in file /crypto/ec/ec lib.[o|c] 


void FIPS ec group set asnl flag(EC GROUP *group, int flag) 
<-> group 
> flag 
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FIPS ec group set curve gf2m (renames EC GROUP set curve GF2m) in file 
./crypto/ec/ec_lib.[o|c] 


int FIPS ec group set curve gfm(EC GROUP *group, const BIGNUM *p, const BIGNUM 
*a, const BIGNUM *b, BN CTX *ctx) 
<-> group 


ux p 

a a 

-> b 

<- ctx 

<- Return 


FIPS ec group set curve gfp (renames EC GROUP set curve GFp) in file /crypto/ec/ec lib.[o| 
c] 


int FIPS ec group set curve gfp(EC GROUP *group, const BIGNUM *p, const BIGNUM *a, 
const BIGNUM *b, BN CTX *ctx) 
<-> group 


I p 

zx a 

-> b 

<- ctx 

<- Return 


FIPS ec group set curve name (renames EC GROUP set curve name) in file /crypto/ec/ec lib. 


[ole] 


void FIPS ec group set curve name(EC GROUP “group, int nid) 
<-> group 
-> nid 


FIPS ec group set generator (renames EC GROUP set generator) in file /crypto/ec/ec lib.[o|c] 


int FIPS ec group set generator(EC GROUP “group, const EC POINT “generator, const 
BIGNUM *order, const BIGNUM *cofactor) 

<-> group 

-— generator 


> order 
> cofactor 
<- Return 
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FIPS ec group set point conversion form (renames EC GROUP set point conversion form) in 
file /crypto/ec/ec lib.[o|c] 


void FIPS ec group set point conversion form(EC GROUP *group, point conversion form t 
form) 

<-> group 

> form 


FIPS ec key check key (renames EC KEY check key) in file /crypto/ec/ec key.[o|c] 


int FIPS ec key check key(const EC KEY *key) 
-> key 
<- Return 


FIPS ec key clear flags (renames EC KEY clear flags) in file ./crypto/ec/ec_key.[o|c] 


void FIPS ec key clear flags(EC KEY *key, int flags) 
<> key 
-> flags 


FIPS ec key copy (renames EC KEY copy) in file /crypto/ec/ec key.[o|c] 


EC KEY *FIPS ec key copy(EC KEY *dst, const EC KEY *src) 


<> dst 
-> src 
<- Return 


FIPS ec key dup (renames EC KEY dup) in file ./crypto/ec/ec_key.[o|c] 


EC KEY *FIPS ec key dup(const EC KEY *src) 
-> src 
<- Return 


FIPS ec key free (renames EC KEY free) in file ./crypto/ec/ec_key.[o|c] 
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void FIPS ec key free(EC KEY *key) 
<> key 


FIPS ec key generate key (renames EC KEY generate key) in file ./crypto/ec/ec_key.[o|c] 


int FIPS ec key generate key(EC KEY *key) 
<-> key 
<- Return 


FIPS ec key get) group (renames EC KEY get) group) in file ./crypto/ec/ec_key.[o|c] 


const EC GROUP *FIPS ec key get) group(const EC KEY *key) 
> key 
<- Return 


FIPS ec key get) private key (renames EC KEY get) private key) in file /crypto/ec/ec key.[o| 
c] 


const BIGNUM *FIPS ec key get) private key(const EC KEY *key) 
> key 
<- Return 


FIPS ec key get) public key (renames EC KEY get public key) in file ./crypto/ec/ec_key.[o| 
c] 


const EC POINT *FIPS ec key get) public key(const EC KEY *key) 
> key 
<- Return 


FIPS ec key get conv form (renames EC KEY get conv form) in file /crypto/ec/ec key.[olc] 


point conversion form t FIPS ec key get conv_form(const EC KEY *key) 
> key 
<- Return 


FIPS ec key get enc flags (renames EC KEY get enc flags) in file /crypto/ec/ec key.[o|c] 
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unsigned FIPS ec key get enc flags(const EC KEY *key) 
> key 
<- Return 


FIPS ec key get flags (renames EC KEY get flags) in file ./crypto/ec/ec_key.[o|c] 


int FIPS ec key get flags(const EC KEY *key) 
> key 
<- Return 


FIPS ec key get key method data (renames EC KEY get key method data) in file 
/crypto/ec/ec_key.[o|c] 


void *FIPS ec key get key method data(EC KEY “key, void *(*dup func)(void *), void 
(“free func)(void *), void (“clear free func)(void *)) 

<> key 

<-> dup func 

<-> free func 

<-> clear free func 

<- Return 


FIPS ec key insert key method data (renames EC KEY insert key method data) in file 
Jerypto/ec/ec_key.[olc] 


void FIPS ec key insert key method data(EC KEY *key, void *data, void *(*dup func)(void 
*), void (*free func)(void *), void (“clear free func)(void *)) 

<> key 

<-> data 

<-> dup func 

<-> free func 

<-> clear free func 


FIPS ec key new (renames EC KEY new) in file /crypto/ec/ec key.[o|c] 


EC KEY *FIPS ec key new() 
<- Return 
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FIPS ec key new by curve name (renames EC KEY new by curve name) in file 
Jerypto/ec/ec_key.[olc] 


EC KEY *FIPS ec key new by curve name(int nid) 
-> nid 
<- Return 


FIPS ec key precompute mult (renames EC KEY precompute mult) in file ./crypto/ec/ec_key. 
Lol] 


int FIPS ec key precompute mult(EC KEY *key, BN_CTX *ctx) 


<> key 
<- ctx 
<- Return 


FIPS ec key set asnl flag (renames EC KEY set asnl flag) in file /crypto/ec/ec key.[o|c] 


void FIPS ec key set asnl flag(EC KEY *eckey, int asnl flag) 
<-> eckey 
->  asnl flag 


FIPS ec key set conv form (renames EC KEY set conv form) in file /crypto/ec/ec key.[o|c] 


void FIPS ec key set conv form(EC KEY *eckey, point conversion form t cform) 
<->  eckey 
->  cform 


FIPS ec key set enc flags (renames EC KEY set enc flags) in file /crypto/ec/ec key.[olc] 


void FIPS ec key set enc flags(EC KEY *eckey, unsigned int flags) 
<->  eckey 
-^ flags 


FIPS ec key set flags (renames EC KEY set flags) in file /crypto/ec/ec key.[o|c] 
void FIPS ec key set flags(EC KEY *key, int flags) 


<> key 
> flags 
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FIPS ec key set group (renames EC KEY set group) in file ./crypto/ec/ec_key.[o|c] 


int FIPS ec key set group(EC KEY *key, const EC GROUP *group) 


<> key 
-> group 
<- Return 


FIPS ec key set private key (renames EC KEY set private key) in file ./crypto/ec/ec_key.[o|c] 


int FIPS ec key set private key(EC KEY *key, const BIGNUM *prv) 


<> key 
-> prv 
<- Return 


FIPS ec key set public key (renames EC KEY set public key) in file ./crypto/ec/ec_key.[o|c] 


int FIPS ec key set public key(EC KEY “key, const EC POINT *pub) 


<> key 
> pub 
<- Return 


FIPS ec key set public key affine coordinates (renames 
EC KEY set public key affine coordinates) in file ./crypto/ec/ec key.[o|c] 


int FIPS ec key set public key affine coordinates(EC KEY *key, BIGNUM *x, BIGNUM 
x 
y) 


<> key 
<-> x 

<-> y 

<- Return 


FIPS ec key up ref (renames EC KEY up ref) in file /crypto/ec/ec key.[olc] 


int FIPS ec key up ref(EC KEY *key) 
<> key 
<- Return 
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FIPS ec method get field type (renames EC METHOD get field type) in file 
./crypto/ec/ec_lib.[o|c] 


int FIPS_ec_method_get field type(const EC METHOD *meth) 
-> meth 
<- Return 


FIPS ec point clear free (renames EC POINT clear free) in file ./crypto/ec/ec_lib.[o|c] 


void FIPS ec point clear free(EC POINT *point) 
<-> point 


FIPS ec point free (renames EC POINT free) in file ./crypto/ec/ec_lib.[o|c] 


void FIPS ec point free(EC POINT *point) 
<-> point 


FIPS ec point get affine coordinates gf2m (renames 
EC POINT get affine coordinates GF2m) in file ./crypto/ec/ec_lib.[o|c] 


int FIPS ec point get affine coordinates gf2m(const EC GROUP *group, const EC POINT 
*p. BIGNUM *x, BIGNUM *y, BN CTX *ctx) 


> group 
E» p 

<-> x 

<-> y 

<- ctx 

<- Return 


FIPS ec point get affine coordinates gfp (renames EC POINT get affine coordinates GFp) in 
file /crypto/ec/ec lib.[o|c] 


int FIPS ec point get affine coordinates gfp(const EC GROUP “group, const EC POINT *p, 
BIGNUM *x, BIGNUM *y, BN CTX *ctx) 


-> group 
> p 
<-> x 
<-> y 
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<- ctx 
<- Return 


FIPS ec point get jprojective coordinates gfp (renames 
EC POINT get Jprojective coordinates GFp) in file /crypto/ec/ec lib.[o|c] 


int FIPS ec point get jprojective coordinates gfp(const EC GROUP *group, const 
EC POINT *p, BIGNUM *x, BIGNUM *y, BIGNUM *z, BN CTX *ctx) 
-^ group 


E» p 

<-> X 

<-> y 

<-> Z 

<- ctx 

<- Return 


FIPS ec point is at infinity (renames EC POINT is at infinity) in file /crypto/ec/ec. lib.[o|c] 


int FIPS ec point is at infinity(const EC GROUP *group, const EC POINT *p) 


-> group 
=> p 
<- Return 


FIPS ec point is on curve (renames EC POINT is on curve) in file ./crypto/ec/ec_lib.[o|c] 


int FIPS ec point is on curve(const EC GROUP *group, const EC POINT “point, BN CTX 
*ctx) 


-> group 
-> point 
<- ctx 

<- Return 


FIPS ec point make affine (renames EC POINT make affine) in file ./crypto/ec/ec_lib.[o|c] 


int FIPS ec point make affine(const EC GROUP *group, EC POINT *point, BN CTX *ctx) 


-> group 
<-> point 
<- ctx 

<- Return 
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FIPS ec point method of (renames EC POINT method of) in file /crypto/ec/ec lib.[o|c] 


const EC METHOD *FIPS ec point method of(const EC POINT *point) 
-^ point 
<- Return 


FIPS ec point mul (renames EC POINT mul) in file ./crypto/ec/ec_lib.[o|c] 


int FIPS ec point mul(const EC GROUP *group, EC POINT *r, const BIGNUM *n, const 
EC POINT *q, const BIGNUM *m, BN CTX *ctx) 


— group 
<-> T 

=> n 

=> q 

=> m 

<- ctx 

<- Return 


FIPS ec point new (renames EC POINT new) in file ./crypto/ec/ec_lib.[o|c] 


EC POINT *FIPS ec point new(const EC GROUP *group) 
-^ group 
<- Return 


FIPS ec point set to infinity (renames EC POINT set to infinity) in file ./crypto/ec/ec_lib.[o|c] 


int FIPS ec point set to infinity(const EC GROUP *group, EC POINT *point) 


-> group 
<-> point 
<- Return 


FIPS ec points make affine (renames EC POINTS make affine) in file ./crypto/ec/ec_lib.[o|c] 


int FIPS ec points make affine(const EC GROUP *group, size t num, EC POINT *points, 
BN CTX *ctx) 

-^ group 

-> num 
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<-> points 
< ctx 
<- Return 


FIPS ecdh compute key (renames ECDH compute key) in file /crypto/ecdh/ech key.[o|c] 


int FIPS ecdh compute key(void “out, size t outlen, const EC POINT *pub key, EC KEY 
*ecdh, void *(*KDE)(const void *in, size t inlen, void *out, size t *outlen)) 
<-> out 


> outlen 
-> pub key 
<->  ecdh 

> KDF 

<- Return 


FIPS ecdh openssl (renames ECDH OpenSSL) in file ./crypto/ecdh/ech_ossl.[o|c] 


const ECDH METHOD *FIPS ecdh openssl() 
<- Return 


FIPS ecdsa openssl (renames ECDSA OpenSSL) in file ./crypto/ecdsa/ecs_ossl.[o|c] 


const ECDSA METHOD *FIPS_ecdsa_openssl() 
<- Return 


FIPS ecdsa sig free (reimplements ECDSA SIG free) in file /fips/ecdsa/fips ecdsa lib.[o|c] 


void FIPS ecdsa sig free(ECDSA SIG *sig) 
<> sig 


FIPS ecdsa sig new (reimplements ECDSA SIG new) in file /fips/ecdsa/fips ecdsa lib.[o|c] 


ECDSA SIG *FIPS ecdsa sig new() 
<- Return 


FIPS ecdsa sign in file ./fips/ecdsa/fips ecdsa sign.[o|c] 
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ECDSA_SIG * FIPS ecdsa sign(EC KEY *key, const unsigned char *msg, size t msglen, const 
EVP MD *mhash) 

<> key 

-> msg 

->  J msglen 

->  mhash 

<- Return 


FIPS ecdsa sign ctx in file /fips/ecdsa/fips ecdsa sign.[o|c] 


ECDSA_SIG * FIPS_ecdsa_sign_ctx(EC_KEY *key, EVP MD CTX *ctx) 


<> key 
<- ctx 
<- Return 


FIPS ecdsa sign digest in file /crypto/ecdsa/ecs ossl.[o|c] 


ECDSA SIG * FIPS ecdsa sign digest(EC KEY *key, const unsigned char “dig, int dlen) 
<-> key 


> dig 
> dlen 
<- Return 


FIPS ecdsa verify in file /fips/ecdsa/fips ecdsa sign.[o|c] 


int FIPS_ecdsa_verify(EC_KEY *key, const unsigned char *msg, size_t msglen, const EVP_MD 
*mhash, ECDSA_SIG *s) 

<> key 

-^ msg 

->  J msglen 

->  mhash 

<-> S 

<- Return 


FIPS ecdsa verify ctx in file /fips/ecdsa/fips ecdsa sign.[olc] 


int FIPS ecdsa verify ctx(EC KEY “key, EVP MD CTX *ctx, ECDSA SIG *s) 
<-> key 
< ctx 
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<-> S 
<- Return 


FIPS ecdsa verify digest in file /crypto/ecdsa/ecs ossl.[olc] 


int FIPS ecdsa verify digest(EC KEY *key, const unsigned char *dig, int dlen, ECDSA SIG 
*s) 


<> key 

> dig 

> dlen 
<-> S 

<- Return 


FIPS evp aes 128 cbc (renames EVP aes 128 cbc) in file /crypto/evp/e aes.[o|c] 


const EVP CIPHER *FIPS evp aes 128 cbc() 
<- Return 


FIPS evp aes 128 ccm (renames EVP aes 128 ccm) in file /crypto/evp/e aes.[o|c] 


const EVP_CIPHER *FIPS evp aes 128 cem() 
<- Return 


FIPS evp aes 128 cfbl (renames EVP aes 128 cfbl) in file ./crypto/evp/e_aes.[o|c] 


const EVP CIPHER *FIPS evp aes 128 _cfb1() 
<- Return 


FIPS evp aes 128 cfb128 (renames EVP aes 128 cfb128) in file ./crypto/evp/e_aes.[o|c] 


const EVP_CIPHER *FIPS evp aes 128 cfb128() 
<- Return 


FIPS evp aes 128 cfb8 (renames EVP aes 128 cfb8) in file ./crypto/evp/e_aes.[o|c] 


const EVP CIPHER *FIPS evp aes 128 cfb8() 
<- Return 
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FIPS evp aes 128 ctr (renames EVP aes 128 ctr) in file /crypto/evp/e aes.[o|c] 


const EVP_CIPHER *FIPS evp aes 128 ctr() 
<- Return 


FIPS evp aes 128 ecb (renames EVP aes 128 ecb) in file /crypto/evp/e aes.[o|c] 


const EVP_CIPHER *FIPS evp aes 128 ecb() 
<- Return 


FIPS evp aes 128 gcm (renames EVP aes 128 gcm) in file ./crypto/evp/e_aes.[o|c] 


const EVP CIPHER *FIPS evp aes 128 gcm() 
<- Return 


FIPS evp aes 128 ofb (renames EVP aes 128 ofb) in file /crypto/evp/e aes.[o|c] 


const EVP_CIPHER *FIPS evp aes 128 ofb() 
<- Return 


FIPS evp aes 128 xts (renames EVP aes 128 xts) in file /crypto/evp/e aes.[o|c] 


const EVP CIPHER *FIPS evp aes 128 xts() 
<- Return 


FIPS evp aes 192 cbc (renames EVP aes 192 cbc) in file /crypto/evp/e aes.[o|c] 


const EVP_CIPHER *FIPS evp aes 192 cbc() 
<- Return 


FIPS evp aes 192 ccm (renames EVP aes 192 ccm) in file /crypto/evp/e aes.[o|c] 


const EVP_CIPHER *FIPS evp aes 192 cem() 
<- Return 
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FIPS evp aes 192 cfbl (renames EVP aes 192 cfbl) in file ./crypto/evp/e_aes.[o|c] 


const EVP_CIPHER *FIPS evp aes 192 cfb1() 
<- Return 


FIPS evp aes 192 cfb128 (renames EVP aes 192 cfb128) in file /crypto/evp/e aes.[o|c] 


const EVP_CIPHER *FIPS_evp_aes_192 cfb128() 
<- Return 


FIPS evp aes 192 cfb8 (renames EVP aes 192 cfb8) in file ./crypto/evp/e_aes.[o|c] 


const EVP_CIPHER *FIPS evp aes 192 cfb8() 
<- Return 


FIPS evp aes 192 ctr (renames EVP aes 192 ctr) in file /crypto/evp/e aes.[o|c] 


const EVP_CIPHER *FIPS evp aes 192 ctr() 
<- Return 


FIPS evp aes 192 ecb (renames EVP aes 192 ecb) in file /crypto/evp/e aes.[o|c] 


const EVP CIPHER *FIPS evp aes 192 ecb() 
<- Return 


FIPS evp aes 192 gcm (renames EVP aes 192 gcm) in file ./crypto/evp/e_aes.[o|c] 


const EVP_CIPHER *FIPS evp aes 192 gcm() 
<- Return 


FIPS evp aes 192 ofb (renames EVP aes 192 ofb) in file /crypto/evp/e aes.[o|c] 


const EVP_CIPHER *FIPS evp aes 192 ofb() 
<- Return 


Page 203 of 225 


User Guide - OpenSSL FIPS Object Module v2.0 


FIPS evp aes 256 cbc (renames EVP aes 256 cbc) in file /crypto/evp/e aes.[o|c] 


const EVP CIPHER *FIPS evp aes 256 cbc() 
<- Return 


FIPS evp aes 256 ccm (renames EVP aes 256 ccm) in file /crypto/evp/e aes.[o|c] 


const EVP CIPHER *FIPS evp aes 256 cem() 
<- Return 


FIPS evp aes 256 cfbl (renames EVP aes 256 cfbl) in file ./crypto/evp/e_aes.[o|c] 


const EVP_CIPHER *FIPS evp aes 256_cfb1() 
<- Return 


FIPS evp aes 256 cfb128 (renames EVP aes 256 cfb128) in file /crypto/evp/e aes.[o|c] 


const EVP_CIPHER *FIPS evp aes 256 cfb128() 
<- Return 


FIPS evp aes 256 cfb8 (renames EVP aes 256 cfb8) in file ./crypto/evp/e_aes.[o|c] 


const EVP CIPHER *FIPS evp aes 256 cfb8() 
<- Return 


FIPS evp aes 256 ctr (renames EVP aes 256 ctr) in file ./crypto/evp/e aes.[o|c] 


const EVP_CIPHER *FIPS evp aes 256 ctr() 
<- Return 


FIPS evp aes 256 ecb (renames EVP aes 256 ecb) in file /crypto/evp/e aes.[o|c] 


const EVP_CIPHER *FIPS evp aes 256 ecb() 
<- Return 
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FIPS evp aes 256 gcm (renames EVP aes 256 gcm) in file ./crypto/evp/e_aes.[o|c] 


const EVP CIPHER *FIPS evp aes 256 gcm() 
<- Return 


FIPS evp aes 256 ofb (renames EVP aes 256 ofb) in file /crypto/evp/e aes.[o|c] 


const EVP CIPHER *FIPS evp aes 256 ofb() 
<- Return 


FIPS evp aes 256 xts (renames EVP aes 256 xts) in file /crypto/evp/e aes.[o|c] 


const EVP CIPHER *FIPS evp aes 256 xts() 
<- Return 


FIPS evp des ede (renames EVP des ede) in file /crypto/evp/e des3.[olc] 


const EVP_CIPHER *FIPS_evp_des_ede() 
<- Return 


FIPS evp des ede3 (renames EVP des ede3) in file ./crypto/evp/e_des3.[o|c] 


const EVP_CIPHER *FIPS evp des ede3() 
<- Return 


FIPS evp des ede3 cbc (renames EVP des ede3 cbc) in file ./crypto/evp/e_des3.[o|c] 


const EVP CIPHER *FIPS evp des ede3 cbc() 
<- Return 


FIPS evp des ede3 cfbl (renames EVP des ede3 cfbl) in file /crypto/evp/e des3.[o|c] 


const EVP_CIPHER *FIPS evp des ede3_cfb1() 
<- Return 
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FIPS evp des ede3 cfb64 (renames EVP des ede3 cfb64) in file ./crypto/evp/e des3.[o|c] 


const EVP CIPHER *FIPS evp des ede3 cfb64() 
<- Return 


FIPS evp des ede3 cfb8 (renames EVP des ede3 cfb8) in file /crypto/evp/e des3.[o|c] 


const EVP_CIPHER *FIPS evp des ede3 cfb8() 
<- Return 


FIPS evp des ede3 ecb (renames EVP des ede3 ecb) in file ./crypto/evp/e_des3.[o|c] 


const EVP CIPHER *FIPS evp des ede3 ecb() 
<- Return 


FIPS evp des ede3 ofb (renames EVP des ede3 ofb) in file ./crypto/evp/e_des3.[o|c] 


const EVP CIPHER *FIPS evp des ede3 ofb() 
<- Return 


FIPS evp des ede cbc (renames EVP des ede cbc) in file ./crypto/evp/e_des3.[o|c] 


const EVP CIPHER *FIPS evp des ede cbc() 
<- Return 


FIPS evp des ede cfb64 (renames EVP des ede cfb64) in file ./crypto/evp/e_des3.[o|c] 


const EVP CIPHER *FIPS evp des ede cfb64() 
<- Return 


FIPS evp des ede ecb (renames EVP des ede ecb) in file /crypto/evp/e des3.[o|c] 


const EVP CIPHER *FIPS evp des ede ecb() 
<- Return 
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FIPS evp des ede ofb (renames EVP des ede ofb) in file ./crypto/evp/e_des3.[o|c] 


const EVP CIPHER *FIPS evp des ede ofb() 
<- Return 


FIPS evp dss (renames EVP dss) in file ./crypto/evp/m dss.[o|c] 


const EVP MD *FIPS evp dss() 
<- Return 


FIPS evp dssl (renames EVP dss1) in file /crypto/evp/m dssl.[o|c] 


const EVP MD *FIPS_evp_dss10 
<- Return 


FIPS evp ecdsa (renames EVP ecdsa) in file ./crypto/evp/m ecdsa.[o|c] 


const EVP MD *FIPS evp ecdsa() 
<- Return 


FIPS evp enc null (renames EVP enc null) in file ./crypto/evp/e_null.[o|c] 


const EVP CIPHER *FIPS evp enc null() 
<- Return 


FIPS evp shal (renames EVP shal) in file /crypto/evp/m shal.[o|c] 


const EVP_MD *FIPS_evp_sha1() 
<- Return 


FIPS evp sha224 (renames EVP_sha224) in file ./crypto/evp/m_shal.[olc] 


const EVP MD *FIPS evp sha224() 
<- Return 


Page 207 of 225 


User Guide - OpenSSL FIPS Object Module v2.0 


FIPS evp sha256 (renames EVP_sha256) in file /crypto/evp/m shal.[o|c] 


const EVP MD *FIPS evp sha256() 
<- Return 


FIPS evp sha384 (renames EVP_sha384) in file ./crypto/evp/m shal.[o|c] 


const EVP MD *FIPS evp sha384() 
<- Return 


FIPS evp sha512 (renames EVP_sha512) in file ./crypto/evp/m_shal.[olc] 


const EVP MD *FIPS evp sha512() 
<- Return 


FIPS free (reimplements CRYPTO free) in file ./fips/utl/fips mem.[o|c] 


void FIPS free(void *ptr) 
<-> ptr 


FIPS get cipherbynid in file /fips/utl/fips enc.[o|c] 


const struct evp cipher st *FIPS get cipherbynid(int nid) 
-> nid 
<- Return 


FIPS get default drbg in file /fips/rand/fips drbg rand.[o|c] 


DRBG CTX *FIPS get default drbg() 
<- Return 


FIPS get digestbynid in file /fips/utl/fips md.[o|c] 


const struct env md st *FIPS get digestbynid(int nid) 
-> nid 
<- Return 
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FIPS get timevec in file /fips/rand/fips rand.[olc] 


void FIPS get timevec(unsigned char *buf, unsigned long *pctr) 
< buf 
<> petr 


FIPS hmac (renames HMAC) in file /crypto/hmac/hmac.[olc] 


unsigned char *FIPS hmac(const EVP MD *evp md, const void *key, int key len, const 
unsigned char *d, size t n, unsigned char *md, unsigned int *md len) 
>  evp md 


-^ key 

-> key len 
-> d 

E» n 

<- md 

<- md len 
<- Return 


FIPS hmac ctx cleanup (renames HMAC CTX cleanup) in file ./crypto/hmac/hmac.[o|c] 


void FIPS hmac ctx cleanup(HMAC CTX *ctx) 
< ctx 


FIPS hmac ctx copy (renames HMAC CTX copy) in file ./crypto/hmac/hmac.[o|c] 


__owur int FIPS hmac ctx copy(HMAC CTX *detx, HMAC CTX *sctx) 
<- detx 

<= Sctx 

<- Return 


FIPS hmac ctx init (renames HMAC CTX init) in file ./crypto/hmac/hmac.[o|c] 


void FIPS hmac ctx init(HMAC CTX *ctx) 
< ctx 


FIPS hmac ctx set flags (renames HMAC CTX set flags) in file ./crypto/hmac/hmac.[o|c] 
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void FIPS hmac ctx set flags(HMAC CTX *ctx, unsigned long flags) 
< ctx 
> flags 


FIPS hmac final (renames HMAC Final) in file /crypto/hmac/hmac.[o|c] 


. owur int FIPS hmac final(HMAC CTX *ctx, unsigned char *md, unsigned int *len) 
<= ctx 


<- md 
<- len 
<- Return 


FIPS hmac init (renames HMAC Init) in file ./crypto/hmac/hmac.[o|c] 


. owur int FIPS hmac init(HMAC CTX *ctx, const void “key, int len, const EVP_MD *md) 
<= ctx 


> key 
> len 
> md 
< Return 


FIPS hmac init ex (renames HMAC Init ex) in file ./crypto/hmac/hmac.[o|c] 


. owur int FIPS_hmac_init_ex(HMAC_CTX “ctx, const void *key, int len, const EVP MD *md, 
ENGINE *impl) 


<- ctx 

> key 

-> len 

-> md 
<-> impl 
<- Return 


FIPS hmac update (renames HMAC Update) in file ./crypto/hmac/hmac.[o|c] 


. owur int FIPS hmac update(HMAC CTX *ctx, const unsigned char *data, size_t len) 
< ctx 


> data 
> len 
<- Return 
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FIPS incore fingerprint in file ./fips/fips.[o|c] 


unsigned int FIPS incore fingerprint(unsigned char *sig, unsigned int len) 


<- sig 
-> len 
<- Return 


FIPS lock (reimplements CRYPTO lock) in file ./fips/utl/fips Ick.[o|c] 


void FIPS lock(int mode, int type, const char *file, int line) 


> mode 
2 type 
> file 
> line 


FIPS malloc (reimplements CRYPTO malloc) in file ./fips/utl/fips mem.[olc] 


void *FIPS malloc(int num, const char “file, int line) 


-> num 
-> file 

-> line 

<- Return 


FIPS md ctx cleanup (reimplements EVP MD CTX cleanup) in file /fips/utl/fips_md.[olc] 


int FIPS md ctx cleanup(EVP MD CTX *ctx) 
< ctx 
<- Return 


FIPS md ctx copy (reimplements EVP MD CTX copy ex) in file ./fips/utl/fips_md.[o|c] 


_ owur int FIPS md ctx copy(EVP MD CTX *out, const EVP MD CTX *in) 
<- out 

-> in 

<- Return 
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FIPS md ctx create (reimplements EVP MD CTX create) in file /fips/utl/fips_md.[olc] 


EVP MD CTX *FIPS md ctx create() 
<- Return 


FIPS md ctx destroy (reimplements EVP MD CTX destroy) in file ./fips/utl/fips_md.[o|c] 


void FIPS md ctx destroy(EVP MD CTX *ctx) 
< ctx 


FIPS md ctx init (reimplements EVP MD CTX init) in file /fips/utl/fips_md.[olc] 


void FIPS md ctx init(EVP MD CTX *ctx) 
<- ctx 


FIPS module mode in file ./fips/fips.[o|c] 


int FIPS_module_mode() 
<- Return 


FIPS module mode set in file ./fips/fips.[o|c] 


int FIPS_module_mode_set(int onoff, const char *auth) 


-> onoff 
-> auth 
<- Return 


FIPS module version in file /fips/fips.[o|c] 


unsigned long FIPS module version() 
<- Return 


FIPS module version text in file ./fips/fips.[o|c] 


const char *FIPS module version text() 
<- Return 
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FIPS openssl cleanse (renames OPENSSL cleanse) in file ./crypto/x86cpuid.[o|c] 


void FIPS openssl cleanse(void *ptr, size t len) 
<> ptr 
> len 


FIPS openssl showfatal (renames OPENSSL showfatal) in file ./crypto/cryptlib.[o|c] 


void FIPS_openssl_showfatal(const char *fmta, …) 
> fmta 
= 


FIPS openssldie (renames OpenSSLDie) in file ./crypto/cryptlib.[o|c] 


void FIPS openssldie(const char “file, int line, const char *assertion) 
> file 

-> line 

-> assertion 


FIPS post set callback in file /fips/fips post.[o|c] 


void FIPS post set callback(int (*post cb)(int op, int id, int subid, void *ex)) 
<- post cb 


FIPS put error (reimplements ERR put error) in file /fips/utl/fips err.[o|c] 


void FIPS put error(int lib, int func, int reason, const char “file, int line) 
> lib 


-> func 
-> reason 
-> file 

-> line 


FIPS rand add (reimplements RAND add) in file /fips/rand/fips rand lib.[o|c] 


void FIPS rand add(const void *buf, int num, double entropy) 
-> buf 
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-> num 
-> entropy 


FIPS rand bytes (reimplements RAND bytes) in file /fips/rand/fips rand lib.[olc] 


int FIPS rand bytes(unsigned char *buf, int num) 


<- buf 
-> num 
<- Return 


FIPS rand get method in file /fips/rand/fips rand lib.[o|c] 


const RAND METHOD *FIPS rand get method() 
<- Return 


FIPS rand pseudo bytes (reimplements RAND pseudo bytes) in file /fips/rand/fips rand lib.[o| 
c] 


int FIPS rand pseudo bytes(unsigned char *buf, int num) 


<- buf 
-> num 
<- Return 


FIPS rand seed (reimplements RAND seed) in file /fips/rand/fips rand lib.[olc] 


void FIPS rand seed(const void *buf, int num) 
-> buf 


-> num 


FIPS rand set bits in file /fips/rand/fips rand lib.[o|c] 


void FIPS rand set bits(int nbits) 
->  nbits 


FIPS rand set method in file /fips/rand/fips rand lib.[o|c] 


int FIPS rand set method(const RAND METHOD *meth) 
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-> meth 
<- Return 


FIPS rand status (reimplements RAND status) in file /fips/rand/fips rand lib.[o|c] 


int FIPS rand status() 
<- Return 


FIPS rand strength in file /fips/rand/fips rand lib.[o|c] 


int FIPS_rand_strength() 
<- Return 


FIPS rsa blinding off (renames RSA blinding off) in file ./crypto/rsa/rsa_crpt.[o|c] 


void FIPS_rsa_blinding_off(RSA *rsa) 
<-> rsa 


FIPS rsa blinding on (renames RSA blinding on) in file ./crypto/rsa/rsa_crpt.[o|c] 


int FIPS rsa blinding on(RSA *rsa, BN CTX *ctx) 


<-> rsa 
< ctx 
<- Return 


FIPS rsa flags (renames RSA flags) in file /crypto/rsa/rsa crpt.[o|c] 


int FIPS_rsa_flags(const RSA *r) 
ER r 
<- Return 


FIPS rsa free in file /fips/rsa/fips rsa lib.[o|c] 


void FIPS_rsa_free(struct rsa_st *r) 
<-> r 
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FIPS rsa generate key ex (renames RSA generate key ex) in file ./crypto/rsa/rsa gen.[o|c] 


int FIPS rsa generate key ex(RSA *rsa, int bits, BIGNUM *e, BN GENCB *cb) 
<> rsa 


> bits 
<-> e 

« cb 

«- Return 


FIPS rsa new in file /fips/rsa/fips rsa lib.[o|c] 


struct rsa st *FIPS rsa new() 
<- Return 


FIPS rsa pkcsl ssleay (renames RSA PKCSI SSLeay) in file /crypto/rsa/rsa eay.[o|c] 


const RSA METHOD *FIPS rsa pkcsl ssleay() 
<- Return 


FIPS rsa private decrypt (renames RSA private decrypt) in file /crypto/rsa/rsa crpt.[o|c] 


int FIPS_rsa_private_decrypt(int flen, const unsigned char *from, unsigned char *to, RSA *rsa, 


int padding) 
-> flen 

-> from 

<- to 

<-> rsa 

-> padding 
<- Return 


FIPS _ rsa private encrypt (renames RSA private encrypt) in file /crypto/rsa/rsa crpt.[o|c] 


int FIPS_rsa_private_encrypt(int flen, const unsigned char “from, unsigned char *to, RSA *rsa, 


int padding) 
> flen 
> from 
<- to 
<> rsa 
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-> padding 
<- Return 


FIPS rsa public decrypt (renames RSA public decrypt) in file /crypto/rsa/rsa crpt.[o|c] 


int FIPS_rsa_public_decrypt(int flen, const unsigned char *from, unsigned char *to, RSA *rsa, 


int padding) 
-> flen 

-> from 

<- to 

<-> rsa 

-> padding 
<- Return 


FIPS rsa public encrypt (renames RSA public encrypt) in file /crypto/rsa/rsa crpt.[o|c] 


int FIPS_rsa_public_encrypt(int flen, const unsigned char *from, unsigned char *to, RSA *rsa, 


int padding) 
> flen 

> from 

<- to 

<-> rsa 

-> padding 
<- Return 


FIPS rsa sign in file /fips/rsa/fips rsa sign.[o|c] 


int FIPS_rsa_sign(struct rsa_st *rsa, const unsigned char *msg, int msglen, const struct env md st 
*mhash, int rsa_pad_mode, int saltlen, const struct env_md_st *mgfl Hash, unsigned char *sigret, 
unsigned int *siglen) 

<> rsa 

-> msg 

->  msglen 

-> mhash 

-> rsa pad mode 

-> saltlen 


-> mgflHash 
<- Sigret 

<- siglen 

<- Return 
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FIPS rsa sign ctx in file /fips/rsa/fips rsa sign.[o|c] 


int FIPS rsa sign ctx(struct rsa st *rsa, struct env md ctx st *ctx, int rsa pad mode, int saltlen, 
const struct env md st *mgfl Hash, unsigned char *sigret, unsigned int *siglen) 

<-> rsa 

< ctx 

-> rsa pad mode 

-> saltlen 


->  mgflHash 
<- Sigret 

<- siglen 

<- Return 


FIPS _ rsa sign digest in file /fips/rsa/fips rsa sign.[o|c] 


int FIPS rsa sign digest(struct rsa st *rsa, const unsigned char *md, int md len, const struct 
env md st *mhash, int rsa pad mode, int saltlen, const struct env md st *mgfl Hash, unsigned 
char *sigret, unsigned int *siglen) 

<> rsa 

> md 

-> md len 

-> mhash 

-> rsa pad mode 

->  saltlen 


-> mgflHash 
<- Sigret 

<- siglen 

<- Return 


FIPS rsa size (renames RSA size) in file ./crypto/rsa/rsa_crpt.[o|c] 


int FIPS_rsa_size(const RSA *rsa) 
-> rsa 
<- Return 


FIPS rsa verify in file ./fips/rsa/fips_rsa_sign.[o|c] 


int FIPS rsa verify(struct rsa st *rsa, const unsigned char *msg, int msglen, const struct 
env md st *mhash, int rsa pad mode, int saltlen, const struct env md st *mgflHash, const 
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unsigned char *sigbuf, unsigned int siglen) 
<> rsa 

-> msg 

->  msglen 

-> mhash 

-> rsa pad mode 

-> saltlen 


->  mgflHash 
->  sigbuf 

->  siglen 

<- Return 


FIPS rsa verify ctx in file /fips/rsa/fips rsa sign.[o|c] 


int FIPS rsa verify ctx(structrsa st *rsa, struct env md ctx st *ctx, int rsa pad mode, int 
saltlen, const struct env md st *mgfl Hash, const unsigned char *sigbuf, unsigned int siglen) 
<> rsa 

<- ctx 

-> rsa pad mode 

->  saltlen 


->  mgflHash 
->  sigbuf 

->  siglen 

<- Return 


FIPS rsa verify digest in file ./fips/rsa/fips_rsa_sign.[o|c] 


int FIPS rsa verify digest(struct rsa st *rsa, const unsigned char *dig, int diglen, const struct 
env md st *mhash, int rsa pad mode, int saltlen, const struct env md st *mgflHash, const 
unsigned char *sigbuf, unsigned int siglen) 


<> rsa 
> dig 
->  diglen 


-> mhash 
-> rsa pad mode 
-> saltlen 


-> mgflHash 
-> sigbuf 

-> siglen 

<- Return 
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FIPS rsa x931 derive ex (renames RSA X931 derive ex) in file /crypto/rsa/rsa x931g.[o|c] 


int FIPS rsa x931 derive ex(RSA *rsa, BIGNUM *pl, BIGNUM *p2, BIGNUM “gl, 
BIGNUM *q2, const BIGNUM *Xpl, const BIGNUM *Xp2, const BIGNUM *Xp, const 
BIGNUM *Xql, const BIGNUM *Xq2, const BIGNUM *Xq, const BIGNUM *e, BN GENCB 


*cb) 

<-> rsa 
<> pl 
<-> p2 
<-> ql 
<-> q2 
-> Xpl 
-> Xp 
Pi Xp 
> Xql 
>  Xq2 
-> Xq 
=> e 
<> cb 
<- Return 


FIPS rsa x931 generate key ex (renames RSA X931 generate key ex) in file 
Jerypto/rsa/rsa_x931g.[olc] 


int FIPS rsa x931 generate key ex(RSA *rsa, int bits, const BIGNUM *e, BN GENCB *cb) 
<> rsa 


> bits 

E e 

<> cb 

<- Return 


FIPS selftest in file /fips/fips post.[o|c] 


int FIPS_selftest() 
<- Return 


FIPS selftest aes in file /fips/aes/fips aes selftest.[o|c] 


int FIPS selftest aes() 
<- Return 
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FIPS selftest aes ccm in file /fips/aes/fips aes selftest.[o|c] 


int FIPS selftest aes ccm() 
<- Return 


FIPS selftest aes gcm in file /fips/aes/fips aes selftest.[o|c] 


int FIPS selftest aes gcm() 
<- Return 


FIPS selftest aes xts in file /fips/aes/fips aes selftest.[o|c] 


int FIPS selftest aes xts() 
<- Return 


FIPS selftest check in file ./fips/fips.[o|c] 


void FIPS selftest check() 


FIPS selftest cmac in file /fips/cmac/fips cmac selftest.[o|c] 


int FIPS selftest cmac() 
<- Return 


FIPS selftest des in file /fips/des/fips des selftest.[o|c] 


int FIPS_selftest_des() 
<- Return 


FIPS selftest drbg in file /fips/rand/fips drbg selftest.[o|c] 


int FIPS selftest drbg() 
<- Return 
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FIPS selftest drbg all in file /fips/rand/fips drbg selftest.[o|c] 


int FIPS selftest drbg all() 
<- Return 


FIPS selftest dsa in file /fips/dsa/fips dsa selftest.[olc] 


int FIPS_selftest_dsa() 
<- Return 


FIPS selftest ecdh in file /fips/ecdh/fips ecdh selftest.[o|c] 


int FIPS selftest ecdh() 
<- Return 


FIPS selftest ecdsa in file ./fips/ecdsa/fips ecdsa selftest.[o|c] 


int FIPS_selftest_ecdsa() 
<- Return 


FIPS selftest failed in file /fips/fips.[olc] 


int FIPS selftest failed() 
<- Return 


FIPS selftest hmac in file ./fips/hmac/fips hmac selftest.[o|c] 


int FIPS selftest hmac() 
<- Return 


FIPS selftest rsa in file /fips/rsa/fips rsa selftest.[o|c] 


int FIPS_selftest_rsa() 
<- Return 


Page 222 of 225 


User Guide - OpenSSL FIPS Object Module v2.0 


FIPS selftest shal in file /fips/sha/fips shal_selftest.[o|c] 


int FIPS selftest shal() 
<- Return 


FIPS selftest x931 in file /fips/rand/fips rand selftest.[olc] 


int FIPS_selftest_x931() 
<- Return 


FIPS set error callbacks in file ./fips/utl/fips err.[o|c] 


void FIPS set error callbacks(void (“put cb)(int lib, int func,int reason,const char *file,int line), 
void (*add cb)(int num, va list args)) 

> put cb 

<- add cb 


FIPS set locking callbacks in file ./fips/utl/fips lck.[olc] 


void FIPS set locking callbacks(void (*func)(int mode, int type, const char *file,int line), int 
(*add cb)(int *pointer, int amount, int type, const char *file, int line)) 

-> J func 

-^ add cb 


FIPS set malloc callbacks in file /fips/utl/fips mem.[o|c] 


void FIPS set malloc callbacks(void *(*malloc cb)(int num, const char *file, int line), void 
(*free cb)(void *)) 

-> malloc cb 

<> free cb 


FIPS text end in file /fips/fips end.[o|c] 


void *FIPS text end() 
<- Return 
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FIPS text start in file /fips/fips start.[olc] 


void *FIPS text start() 
<- Return 


FIPS x931 bytes in file ./fips/rand/fips_rand.[o|c] 


int FIPS_x931_bytes(unsigned char *out, int outlen) 


<- out 
-> outlen 
<- Return 


FIPS x931 method in file /fips/rand/fips rand.[o|c] 


const RAND METHOD *FIPS x931 method() 
<- Return 


FIPS x931 reset in file /fips/rand/fips rand.[o|c] 


void FIPS x931 reset() 


FIPS x931 seed in file /fips/rand/fips rand.[o|c] 


int FIPS x931 seed(const void *buf, int num) 


-> buf 
-> num 
<- Return 


FIPS x931 set dt in file /fips/rand/fips rand.[olc] 


int FIPS_x931_set_dt(unsigned char *dt) 
<- dt 
<- Return 


FIPS_x931_set key in file /fips/rand/fips rand.[o|c] 


int FIPS_x931_set_key(const unsigned char *key, int keylen) 
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> key 
->  keylen 
<- Return 


FIPS x931 status in file ./fips/rand/fips_rand.[olc] 


int FIPS_x931_status() 
<- Return 


FIPS_x931_stick in file ./fips/rand/fips_rand.[o|c] 


void FIPS_x931_stick(int onoff) 
-> onoff 


FIPS x931 test mode in file /fips/rand/fips_rand.[olc] 


int FIPS x931 test mode() 
<- Return 
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